工程科学与技术   2017, Vol. 49 Issue (2): 121-132
基于云流量混淆的Tor匿名通信识别方法
何永忠1,2, 李响1,2, 陈美玲1,2, 王伟1,2     
1. 北京交通大学 智能交通数据安全与隐私保护技术北京市重点实验室, 北京 100044;
2. 北京交通大学 计算机与信息技术学院, 北京 100044
基金项目: 国家自然科学基金资助项目(61402035)
摘要: 针对采用云流量混淆Meek机制的Tor匿名通信流量与其他普通云流量难于区分识别的问题,提出了基于流静态特征的Tor匿名通信识别方法和基于支持向量机SVM分类算法的Tor匿名通信识别方法。本文首先从连接特征分析、数据包静态特征分析以及数据流动态特征分析出发,通过对大量Tor-Meek通信流量以及非Tor-Meek通信流量的对比实验研究,确定了7个具有特异性和较强区分度的Tor-Meek通信流量的静态和动态流量征,然后在此基础之上提出了基于特征匹配算法的Tor-Meek匿名通信识别方法,该方法能够快速识别Tor-Meek通信流量,对于包含大于200个包的流识别准确率大于90%。为了进一步适应Tor的版本变化带来的特征改变,基于Meek流分片机制的数据流统计特征分析,分别从长度及个数、长度方差、长度熵、接收发送序列等4个方面,提出了识别Tor-Meek流的16种Tor-Meek流量统计特征,采用SVM分类算法对Tor-Meek流量进行识别,通过系统的实验研究不同特征组合、不同算法参数选择的算法识别准确率和召回率,筛选出最优的特征组合和参数。在实验室环境中搭建实验数据采集平台并采集Tor-Meek通信和其他通信数据进行实验,该算法对长度大于40个包Tor-Meek流的识别准确率大于97%,召回率大于99%,且具有较高的识别效率。实验结果表明,采用特征匹配可以实现对云流量混淆Tor匿名通信的快速识别,而基于流分片统计特征的分类算法对不同Tor通信软件版本的变化具有更高的稳定性和识别准确率。
关键词: 匿名通信    Tor    流量混淆    流量识别    
Identification of Tor Anonymous Communication with Cloud Traffic Obfuscation
HE Yongzhong1,2, LI Xiang1,2, CHEN Meiling1,2, WANG Wei1,2     
1. Beijing Key Lab. of Security and Privacy in Intelligent Transportation, Beijing Jiaotong Univ., Beijing 100044, China;
2. School of Computer and Info. Technol., Beijing Jiaotong Univ., Beijing 100044, China
Abstract: In order to solve the problem of identifying the meek-based Tor anonymous traffic from the TLS-based cloud computing service traffic, an identification method for Tor's anonymous communication based on traffic feature matching and a classification method of Tor's anonymous traffic based on SVM were proposed.Firstly, based on the analysis of connection, static packet and dynamic traffic of the captured Tor-Meek and non Tor-meek traffic in the lab environment, seven specific static and dynamic features of Tor-Meek traffic were identified.Lately, a traffic feature matching identification method for Tor's anonymous communication technique was proposed, which could be used to quickly detect Tor-Meek traffic and the accuracy rate is over 90% for longer traffic with packets number exceeding 200. In order to be robust to the upgrading and transformation of Tor versions, statistic features of the slicing of Tor-Meek traffic were analyzed including the length and count, length variation, length entropy, sequence of sending and receiving of the sliced traffic. Then 16 statistic features were identified, based on which an identification and classification method for Tor's anonymous traffic by using SVM machine learning algorithm was proposed.Different feature combinations and algorithm parameters were studied experimentally to decide which ones can yield the best accuracy and recall rate of the classification algorithm.It was shown that when the number of packets in one session wa above 40, and the length of each slice of one session was 40 packets, the identification accuracy was above 97 and the recall rate was over 99% for the SVM based method.The experiments results show that while the feature matching methods is effective for quick identification, the machine learning method is more accurate and robust to the changing and upgrading of different versions of Tor browser in identifying anonymous traffic of specific versions of Tor-Meek.
Key words: anonymous communication    Tor    traffic obfuscation    traffic identification    

匿名通信技术通过隐藏通信过程中通信双方的身份信息,或者隐藏通信双方的联系,从而有效地实现了对通信实体身份信息的保护[1]。匿名通信技术最早出现在1981年,Chaum提出了基于节点混淆 (Mix) 的匿名通信技术[2]。Mix节点接收多个发送者发来的消息,并对这些消息进行混淆处理,之后将消息发送给接收者,从而使得消息无法被跟踪,实现了匿名通信。目前,匿名通信技术根据实现技术主要可以分为两类:基于重路由的匿名通信技术和基于广播的匿名通信技术。基于重路由的匿名通信技术的典型实现有:Anonymizer[3]、Onion Routing[4]、Mixminion[5]、Crowds[6]等。基于广播的匿名通信技术的典型实现有DC-Net[7]、P5[8]等。

第二代洋葱路由[9](The second generation Onion Router, Tor) 匿名通信系统诞生于2003年,由美国海军研究实验室 (US Naval Research Laboratory) 赞助建立。Tor匿名通信系统是目前应用最为广泛的匿名通信系统。截止到2016年11月,全球一共有大约7 150多个Tor中继节点和2 150个Tor网桥节点,平均每秒产生的流量约为10.1 GB (Tor网桥节点最高曾经达到4 000多个)[10]。全球每天有大约20万用户通过直接连接的方式使用Tor,另外有大约4万用户通过网桥连接的方式使用Tor。Tor采用重路由技术和层层加密技术,有效地抵御了流量分析等各种攻击,为用户提供了良好的隐私保护。然而匿名通信技术在为合法用户提供身份信息保护的同时,也可能被滥用于网上的非法或者犯罪行为,给网络安全带来巨大的威胁。Tor为进一步伪装和隐匿其通信流量,引入了多种集成了传输插件的网桥技术,包括obfs3、obfs4、Meek、Flash proxy、FTE以及scramblesuit等。通过这些技术可以对Tor流量进行流量混淆,以规避对Tor的流量审查和监管。2015年11月,ISIS恐怖组织公布了一份网络安全手册,在这份手册中Tor作为被推荐的浏览器,ISIS称Tor可以“隐藏用户的身份和防止跟踪”。因此,如何识别Tor匿名通信流量并对其实施有效的监管,对保护网络安全打击违法犯罪具有重要意义。

目前,主要的流量识别技术可以分为:基于端口号、基于深层包检测 (deep packet inspection,DPI)、基于行为特征和基于流统计特征的流量识别技术[8]

基于端口号的流量识别方法,所依据的是互联网地址指派机构IANA (Internet Assigned Numbers Authority) 制定的端口号映射表。基于深层包检测的流量识别方法,又称为基于载荷特征的流量识别技术方法。该方法的核心是利用模式匹配算法搜索流量有效载荷 (payload) 中的特征值,从而来对各种不同的应用层协议进行识别。基于行为特征的流量识别方法,是依据传输层的主机行为模式对网络中不同应用的流量进行分类的方法。通过观察流量在传输层中如何连接、如何进行数据交互来判断其属于哪种应用。基于统计特征的流量识别方法,通过建立数据流特征的模型,并分析数据流的统计特征,比如流中数据包的平均大小,数据包到达时间以及数据包的时间间隔等,之后依据这些特征对不同的协议进行区分。对于数据流统计特征的建模、分析,和对数据流的分类,可以采用机器学习的方法,利用数据流的统计特征建立机器学习分类模型,然后选择恰当的机器学习算法来对流量进行分类。

然而与明文流量的识别技术不同,对于加密流量来说,检测者无法提取加密流量内部有效荷载的特征,因此给流量识别带来了更大的难度。为了识别加密流量,必须对使用了同一种加密协议的不同应用的流量进行区分。对使用了同一种加密协议的不同应用的流量进行区分。例如,Tor使用了TLS加密技术对其流量进行加密,因此要对Tor流量进行识别,就要对Tor和非Tor的TLS流量进行分类。

为了提高识别率,针对不同的加密应用应设计不同的识别算法。由于针对Tor匿名通信流量识别采用了TLS加密以及规避审查技术,因此采用基于端口号或者深层包检测等技术不能对其流量进行有效的检测。目前,针对Tor匿名通信流量识别的研究报道较少,例如,何高峰等[11]提出了基于TLS指纹特征和基于报文长度分布特征的Tor匿名通信流量识别方法。通过利用Tor信元的结构和长度等特征,此两种识别方法均能对Tor匿名通信的流量进行有效识别。然而,在Tor Browser 4.0版本引入了Meek传输插件以后,Meek作为Tor的一种特殊的网桥模式,成功地把Tor流量伪装成了基于HTTPS加密的云服务流量 (云流量混淆技术)。一方面,Meek使用了前置域名技术,通过第三方服务器进行流量转发,从而隐藏了正在和Tor网桥通信的事实,使得传输内容看起来是在访问另一个站点。另一方面,Meek使用了基于浏览器代理的加密技术,通过浏览器建立HTTPS隧道传输Tor流量,也就是将Tor的数据流封装成HTTPS的请求和响应序列,从而隐藏了Tor流量原有的特征。因此,上述方法无法对Tor-Meek流量进行有效的识别。

目前,Tor-Meek匿名通信流量识别面临如下待解决的问题:1) 由于Meek通过Amazon、Azure和Google云服务平台对Tor流量进行流量转发,所以其目的IP地址和端口号与其他应用访问这些云服务平台的IP地址和端口号相同,因此无法通过IP地址或端口号来区分Tor-Meek流量和普通的访问云服务平台的流量;2) Meek使用基于浏览器代理的加密技术,通过浏览器建立HTTPS隧道传输Tor流量,从而隐藏了Tor的TLS指纹特征和报文长度等特征,因此无法利用Tor流量原有的特征对Tor-Meek流量进行有效识别;3) Tor-Meek流量是通过TLS协议进行加密的,因此无法通过明文协议特征匹配来识别流量。

本文在搭建的实验环境中捕获Tor-Meek匿名通信流量并对其进行特征分析,包括连接特征分析、数据包静态特征分析、数据流动态特征分析和数据流统计特征分析等,确定了Tor-Meek的流量7种静态和动态特征,以及4类16种统计特征。提出了基于特征匹配的Tor匿名通信识别方法和基于SVM的Tor匿名通信识别方法。实验结果表明,本文提出的方法均可有效识别基于Meek的Tor匿名通信流量,且具有较高的准确率、召回率和性能。

1 Tor与Meek的基本原理 1.1 Tor基本原理

Tor是一个分布式的匿名通信系统,由用户、洋葱代理、洋葱路由器、目录服务器及目标应用服务器等部分组成[12-13]。Tor匿名通信系统架构如图 1所示。

图1 Tor的网络结构 Fig. 1 Network structure of Tor

1) 用户 (Alice):通过Tor网络与外界进行匿名通信的计算机。用户Alice通过洋葱代理来连接到Tor网络。

2) 洋葱代理 (onion proxy,简称OP):洋葱代理是用户Alice在本地系统中运行的代理服务程序。OP的主要功能有两个:一个是负责与本地的上层应用程序进行数据交换;另一个是负责执行匿名通信协议,建立匿名通信链路,接收上层应用的数据,将其封装成Tor信元后发送至匿名通信链路。

3) 洋葱路由器 (onion router,简称OR):洋葱路由器负责建立匿名通信链路和转发数据。所有的OR节点的信息都保存在目录服务器中。

4) 目录服务器 (directory server):目录服务器负责汇总Tor网络运行状态,收集、存储和管理所有的OR节点信息。

5) 网桥节点 (Bridge relays):Bridge节点是一种特殊的OR节点,它不被包含在Tor目录服务器所公开发布的OR节点列表中。当Tor目录服务器或普通的OR节点不能被直接访问时,用户可以直接与Bridge节点进行通信。

6) 目标应用服务器 (Bob):目标应用服务器Bob是通信的目的端,他提供具体的应用服务。

当用户Alice通过Tor网络对目标应用服务器Bob进行访问时,首先Alice的主机上需要安装并运行洋葱代理OP,之后OP连接Tor目录服务器,并从目录服务器上获得Tor节点列表。OP根据自身的访问策略和Tor节点状态,选择3个节点分别作为入口节点,中间节点和出口节点,并在这3个节点之间建立层层加密的匿名通信链路,最终达到目标应用服务器Bob。当Alice需要访问其他站点时,OP会重新为Alice建立另一条匿名链路。

为了提高Tor匿名通信系统的可用性及安全性,Tor引入了一种网桥 (Bridge) 机制[14],通过网桥机制Tor可以有效地抵御网络审查和流分析攻击。网桥机制的核心是网桥节点,它是一种特殊的OR节点,不在Tor目录服务器公开发布的Tor节点目录中,每次用户可以申请获取少量网桥节点,因此比Tor节点更难完全阻断。当Tor目录服务器或者公开的Tor节点不能被直接访问时,Tor客户端可以通过网桥节点获得其它OR节点的信息,并以网桥节点作为连接Tor网络的入口节点进行通信,从而规避了审查。此外Tor网桥还引入了多种流量混淆插件,通过这些流量混淆插件,Tor流量得到了进一步的伪装。

1.2 Meek基本原理

Tor Browser4.0版本中增加了Meek[15-16]传输插件 (pluggable transport),它把Tor流量伪装成了基于HTTPS加密的云服务流量,从而有效地抵御网络审查。目前,Tor支持Meek-Amazon、Meek-Azure和Meek-Google这3个选项,可以分别通过亚马逊云服务、微软云服务和谷歌云服务进行流量转发。

Meek由两部分组成:前置域名技术 (domain fronting) 和基于HTTP的隧道代理 (HTTP-based tunneling proxy)。前置域名技术用于连接至代理服务器;基于HTTP的隧道代理用于将HTTP请求序列转化为Tor数据流。Meek客户端利用一个可以访问的前置域名 (allowed.example) 来保护Tor网桥的域名 (forbidden.example) 不被网络审查发现。前置域服务器在接收到请求后,解密该请求的TLS层,之后根据内部的HTTP请求的Host header将请求发送给Tor网桥。在完成Tor网络的访问之后,Tor网桥以HTTP响应的方式将数据回传给客户端。Meek客户端和Meek服务器是Tor和传输插件之间接口,对于Tor来说Meek客户端和Meek服务器之间是一种不透明的数据传输。Meek工作原理如图 2所示。

图2 Meek工作原理 Fig. 2 Meek's schematic diagram

Meek客户端担任Tor客户端的上层代理。当Meek客户端接收到来自Tor客户端的一组数据时,它把数据封装到POST请求中,并通过前置域名服务将请求转发给Tor网桥。在Tor网桥上运行着一个服务器程序,即Meek服务器,它负责解析该HTTP请求,并把其中的负载内容发送到Tor网络。

在完成Tor网络的访问之后,数据经由Tor网桥返回到客户端。Meek服务器在接收到Tor网桥准备回传给客户端的数据时,先把数据封装到HTTP响应的结构体内,再发送给Meek客户端。Meek客户端在接收到该HTTP响应之后,把其中的内容传送给Tor客户端。这些请求和响应是严格序列化的。Meek客户端直到收到前一个请求的响应之后,才会发送第2个请求。

Meek服务器需要同时处理多个客户端访问,他为每个活动的客户端保持一条连接,并通过session ID标识不同客户的请求。Meek客户端需要在HTTP请求的头部中加入一个session ID。当Meek服务器收到用户请求之后,如果发现该请求的session ID是新的,那么他将为该请求打开一条新的连接,并启动Tor进程连接至Tor网络。

由于HTTP是一个基于请求的协议,它不会主动推送数据到客户端。为了使服务器能够回发数据到客户端,即便在没有数据传输的时候,Meek客户端仍需要发送空的轮询请求 (polling request) 到服务器。这个轮询请求给了服务器回传数据的机会。轮询间隔从100 ms开始,并以指数递增,最大值为5 s。

1.2.1 基于浏览器代理的加密

如果不进行进一步的伪装,Meek并不会破坏Tor原有的TLS指纹特征。Tor在其TLS握手阶段的表现出了其特有的指纹特征,这些特征在文献[17]中已经提到,并且成功地利用这些特征对Tor匿名通信流量进行了识别。

为了隐藏Tor的TLS指纹特征,Meek客户端将其所有HTTPS请求代理给一个真实的浏览器,这样做使得Meek的请求看起来与一般的浏览器请求一样。Tor Browser使用Firefox对它的HTTPS请求进行代理。Meek代理仅运行在后台,而且不提供给用户接口,也不给用户浏览器传递认证状态信息。Tor客户端程序同时启动Meek客户端和一个浏览器程序,之后配置Meek客户端把它的请求代理给浏览器程序。只有这个浏览器,才是真正与互联网进行连接部分。

1.2.2 前置名域技术

前置域名技术主要是为了将被禁止访问的域名转化成可被访问的域名。它将可被访问的域名放置在请求的外部,主要用于DNS查询;并将被禁止访问的域名放置在请求的内部,也就是HTTP请求的HOST Header中。前置域名技术利用了TLS的SNI扩展,客户端可以在TLS握手过程开始的时候指示尝试连接的主机名,这使得服务器可以针对同样的IP地址和TCP端口号呈现多个证书,即同一个IP地址能够访问不同的HTTPS协议的网站或者是其他建立在TLS上的服务,而且不要求所有的站点都使用相同的证书。例如,想要访问http://appspot.com下某个被禁止的子域名,那么采用这用策略后可以伪装成访问http://www.google.com

2 基于特征匹配的识别方法

在文献[15]中提到了Tor-Meek流量具有区别于其他流量的工作特性,其中包括Tor-Meek的TLS密码套件和扩展字段的特殊性、由于轮询请求而产生的心跳现象、以及报文的最大负载长度等。结合实验观察,确定用于Tor-Meek流量识别的特征集合。

在实验网络环境中,通过Wireshark工具捕获Meek流量。在数据采集时,先排除其他干扰流量,关闭除系统运行必须的进程之外的所有进程,保证不会产生干扰的TLS流量。排除干扰后启动Wireshark开始捕获流量。之后启动Tor Browser,选择Meek连接方式进行连接,此时Wireshark便可以捕获到Meek的TLS流量。

基于Tor和Meek的工作原理,对所捕获的Tor流量进行特征分析。数据来源为Tor Browser 4.0.2 ~6.0.5版本。主要特征分析可以分为以下四各方面:1) 连接特征分析:包括Meek的TLS连接个数、持续时间等;2) 数据包静态特征分析:包括TLS握手报文的指纹特征 (如Cipher Suits、Extensions) 等;3) 数据流统计特征分析:包括TLS流的包长分布、延迟规律等;4) 数据流动态特征分析:包括不同网络状态下TLS流接收、发送数据包序列的特征等。

根据以上分析确定Tor-Meek流量的7个特征,然后提出基于特征匹配的识别算法。

2.1 Tor-Meek流量的静态、动态特征 2.1.1 单一链接特征

在通过Meek网桥连接Tor网络时,Meek客户端会建立唯一的一条TLS连接与相应的云服务平台通信。另外,一台PC在同一时间内只允许启动一个Tor Browser进程,而Meek客户端是由Tor Browser在后台调用的,所以一台PC在同一时间内只能启动一个Meek客户端。综合来看,一台PC在同一时间内至多只有一条Meek的TLS连接。

当Meek的TLS连接断开而会话并没有结束时,Meek客户端会为此会话重新建立TLS连接,或者说是恢复TLS连接。这是一种很常见的情况,比如由于网络环境不稳定,出现丢包或者拥塞等情况时,就会出现TLS连接断开并恢复情况。Meek客户端在恢复TLS连接时会使用之前的TLS连接的session ID,并通过TLS恢复会话的握手方式恢复该TLS连接。

2.1.2 有序连接特征

Meek客户端接收到上层的Tor客户端发送来的一组数据时,它将数据封装到一个HTTP请求中,并通过前置域名技术将请求转发给Meek服务器。Meek服务器解释该HTTP请求,之后把其中的负载内容发送到Tor网络。在完成Tor网络的访问之后,Meek服务器同样把数据封装到HTTP响应的结构体内,返回给Meek客户端。Meek客户端在接收到该HTTP响应之后,把其中的内容传送给Tor客户端。HTTP的请求和响应是严格序列化的。也就是说,直到Meek客户端接收到上一个请求的响应之后,才会发送第2个请求。

2.1.3 TLS Cipher Suits特征

Meek的TLS Client Hello中的Cipher Suits与Tor Browser所集成的浏览器的TLS Client Hello中的Cipher Suits相一致,包括Cipher Suits的个数、内容和顺序。例如,Tor Browser 4.0.2集成的浏览器为Firefox ESR 31.3.0,则Tor Browser 4.0.2的Meek网桥的TLS Cipher Suits与Firefox ESR 31.3.0的TLS Cipher Suits相一致。

2.1.4 TLS Extensions特征

Meek的TLS Client Hello中的Extensions与Tor Browser所集成的浏览器的TLS Client Hello中的Extensions相一致,包括Extensions的个数、内容和顺序。

2.1.5 TLS Server Name特征

依据所选择的Meek网桥,Meek的TLS连接Client Hello报文中extension server name可以确定。Meek-Amazon网桥为https://a0.awsstatic.com/,Meek-Azure网桥为https://ajax.aspnetcdn.com/

2.1.6 轮询请求特征

Meek为了保持客户端和服务器之间的连接,即便在没有数据发送的时候,Meek客户端仍需要发送空的轮询请求数据包到服务器,这个轮询请求给了服务器回传数据的机会。本文称这种现象为Meek的轮询请求机制。

Meek的轮询请求机制的工作原理如下:使用Meek网桥连接Tor网络时,Meek客户端在没有数据传输的第100 ms后,发起第1次轮询请求,发送负载内容为空的HTTP请求到Meek服务器,并由Meek服务器传回一个对这个请求的响应。之后等待一段时间间隔,如果仍然没有数据传输,则继续发起第2次轮询请求。每次发起轮询请求所等待的时间比之前一次增加50%,直到最大值5 s。一旦有数据传输,轮询请求过程就立刻结束。当再次出现无数据传输时,轮询请求机制将重新开始。

Meek用于轮询请求的数据包的大小是固定的,其中,Meek-Amazon用于轮询请求机制的数据包大小为:发送包209 byte,接收包395 byte;Meek-Azure用于轮询请求机制的数据包大小为:发送包202 byte,接收包383 byte。

2.1.7 分组传输特征

在使用普通浏览器通过SSL方式下载大文件时,会由客户端发出一个下载请求,之后服务器端开始向本地传输数据,直到文件下载结束,该过程中不会有客户端和服务器端的交互。但是使用Tor Browser下载相同文件时,会有客户端和服务器之间的交互。也就是说,在下载过程中,客户端会向服务器发送数据包,之后再由服务器端返回一组数据包。此外,在每次服务器的响应中,回传的一组数据包中均会有长度较小的数据包的存在。所以Meek表现出了明显的大块数据分组传输的特征。

2.2 基于特征匹配的Tor匿名通信识别方法 2.2.1 主要思想

基于流特征的Tor匿名通信识别方法包含基于Meek TLS静态特征的流量过滤和基于Meek流动态特征的流量识别两部分。

首先,Meek流是一条特殊的TLS流,因此只要识别一条TLS流是否具有Meek流所独有的特征,即可确定该条流是否为Meek流,对于非TLS流可以直接排除。通过筛选TLS流对一般网络流量进行过滤,可以排除大部分的干扰。

Meek在TLS握手阶段,表现出了TLS Client Hello中Cipher Suits、Extensions以及Server Name的指纹特征。这些指纹特征与Tor Browser所集成的浏览器的TLS的指纹特征相一致。目前最新版本的Tor Browser所集成的浏览器为Firefox 38 ESR。根据最新netMarketShare[18]浏览器市场份额统计结果显示:Firefox 38市场份额为0.29%。而使用Firefox特定的版本访问Amazon云服务https://a0.awsstatic.com/或者Azure云服务https://ajax.aspnetcdn.com/将占据更小的比例。所以通过Meek TLS指纹特征对TLS流量进行过滤,之后所需要执行进一步检测的数据流将大幅减少。

Meek的轮询请求机制使得Meek的TLS流呈现出了其独有的特征,包括其用于轮询请求报文的长度和轮询请求的时间规律,这些特征可以作为最终识别Meek流的依据。通过判断一条经过初步过滤的TLS流是否出现了Meek的轮询请求机制,即可判断该TLS流是否为Meek流。

2.2.2 基于静态特征的流量过滤

基于TLS静态特征的流量过滤是通过Meek流在TLS握手阶段Client Hello报文中的指纹特征对待识别的TLS流进行过滤。判断一条待识别的TLS流的Client Hello报文中Cipher Suits字段、Extensions字段以及Server Name信息是否与Meek特征相匹配,从而实现对Meek流的过滤。基于TLS指纹特征的流量过滤方法步骤如下:

步骤1:判断ClientHello报文中的版本信息是否为SSLv3或者TLS。若成立则执行步骤2,否则,判断为其他类型流量。

步骤2:判断ClientHello报文中Cipher Suits个数是否满足Meek特征。若成立则执行步骤3,否则判断为其他类型流量。

步骤3:提取ClientHello报文中Cipher Suits内容,判断其内容和顺序是否符合Meek特征。若成立则执行步骤4,否则,判断为其他类型流量。

步骤4:判断ClientHello报文中Extensions个数是否满足Meek特征。若成立则执行步骤5,否则,判断为其他类型流量。

步骤5:提取ClientHello报文中Extensions内容,判断其内容和顺序是否符合Meek特征。若成立则执行步骤6,否则,判断为其他类型流量。

步骤6:提取ClientHello报文中Server Name内容,判断其内容是否符合Meek特征。若成立则执行成功,否则,判断为其他类型流量。

基于TLS静态特征的流量过滤方法仅需分析TLS流中Client Hello报文,识别速度快,能适用于在线识别。但需要人工对Meek特征进行维护,以适应Meek指纹特征的变化。

2.2.3 基于Meek动态特征的流量识别

基于Meek流动态特征的流量识别是在通过基于TLS指纹特征的流量过滤方法对流量进行初步过滤的基础之上,根据Meek的轮询请求机制所表现出的特征,对待识别的TLS流做最后一步的识别判断,以达到识别Meek流的目的。基于Meek流动态特征的流量识别方法步骤如下:

步骤1:对待识别的TLS流提取特殊长度的数据包,并计算数据包的时间间隔。其中, Meek-Amazon和Meek-Azure特征包长度见第2.1.6节所述。

步骤2:将时间间隔序列带入轮询请求机制判断器进行判断。若判断成功,则该TLS流为Meek流,否则不是。

2.2.4 轮询请求机制判断器

Meek的轮询请求机制是当在没有数据传输的第100 ms时,发起第一次轮询请求,Meek客户端发送一个负载为空的请求给Meek服务器,服务器响应一个负载为空的数据包。之后若仍然没有数据传输,则在第100×(1+50%) ms时发起第2次轮询请求。以此类推,直到最大值5 s,以后每次轮询请求的时间间隔为5 s。按照这个规律计算,一共需要经过11次轮询请求后,轮询请求的时间间隔从100 ms增长到5 s。

轮询请求机制判断器是判断一组待识别的时间间隔序列中,是否含有满足上述时间间隔规律的子序列。若有,则记录轮询请求机制的发起次数,并根据一个阈值来判断是否为Meek流;否则返回失败。

实现方法是通过一个数组pollingScore[8]记录从第1到11次轮询请求所发生的次数。此外还需要约定一个允许范围,用于计算一个时间间隔是否满足轮询请求的时间间隔。由一组时间间隔序列可以计算得到一个记录了轮询请求发起次数的数组pollingScore[],之后根据约定的阈值对该数组进行判断。该阈值由一个二元组确定,即 (第n次轮询请求,发起次数a) 其中n∈(1, 11)。例如第2次轮询请求,发起了3次。对于满足阈值的结果,即可认为是Meek流;否则不是。

3 基于SVM的识别方法

Meek流具有单一链接的特征,也就是说Meek客户端与服务器的通信是建立在单独的一条TLS连接之上的,且同一PC在同一时间内只有一条Meek的TLS连接。Meek的TLS连接可能保持很长的时间,并且在一条TLS连接上可能出现多种网络状态。首先,Meek建立TLS连接。之后Meek利用这条TLS连接与Tor网络建立连接,经过3跳握手后,与Tor网络连接成功。接下来,用户将利用这条TLS连接开始对Tor网络进行访问。用户可能在一段时间内不进行任何操作,这时没有任何网络访问,网络处于空闲状态;用户也可能浏览网页,这时将产生间断的网络访问;用户也可能下载一个较大的文件,这时将在一段时间内产生持续的网络访问,网络处于繁忙状态。由此,提出了Meek流分片模型,核心思想是将一条Meek的TLS流,按数据包接收和发送的时间先后顺序,分割成大小相同的片段,使每个分片内只包含一种网络状态。

基于统计特征和SVM[19]的Tor匿名通信识别方法,其核心思想是在对Meek流进行分片的基础之上,寻找到Meek流所特有的分片,即Meek特征分片。然后为Meek特征分片构建分类器,该分类器可以实现对Meek特征分片和非Meek特征分片的分类。在对一条未知的TLS流进行识别时,首先依据约定的分片规则对该流进行分片,然后利用Meek特征分片分类器对待识别的TLS流的分片进行分类。之后判断该待识别的TLS流中是否包含Meek特征分片,如果包含则该条TLS流为Meek流,否则不是Meek流。

在使用Meek网桥连接Tor网络时,Meek客户端首先与Meek服务器建立连接,之后通过Meek服务器与Tor网络建立连接。在Meek客户端与服务器成功建立TLS连接后,Meek客户端首先会向Meek服务器请求Tor网络状态和Tor节点目录信息,之后通过Meek服务器开始建立Tor链路的3跳握手过程,并进行后续的访问。由于Meek的请求和响应是严格序列化的。所以,在此过程中的每一步,都是有着严格先后顺序的。因此可以选用每个Meek流中的第1个分片,作为Meek特殊分片,用于区分Meek流和非Meek流。

通过Meek流量特征分析可以发现一条Meek流中数据包接收和发送的序列表现出了许多与一般TLS流不同的特征。一方面,在网络空闲时Meek会发起轮询请求机制,有固定字节的数据包按一定的时间规律在客户端和服务器之间传送;另一方面,Meek在传输大量数据时,会呈现出明显的分组传输特征。此外,Meek流是一条有序连接,Meek的请求和响应是严格序列化的。

为表现出Meek流中数据包接收和发送序列的特征,用一组有序的0、1串来表示数据包的接收和发送,0表示接收包,1表示发送包 (根据计算需要,有时用-1和1表示)。之后对该组序列进行随机性检验计算,包括频度检验、游程检验、前向累加和、后向累加和以及位信息熵。通过这些检验值的计算,可以表现出一组序列的随机性,从而表现出Meek流中数据包接收和发送序列的特征。除了接收发送序列特征,本文还选择了长度及个数、长度方差和长度熵3类特征。

此外,为了进行SVM分类,还需要对这些特征值进行了归一化处理,归一化的目的是将每个特征值都映射成为0到1之间的实数,之后组成特征向量。具体的特征值和归一化方法如表 1所示。其中,数据包长度信息熵的归一化处理采用了直接除3的形式,是由于该统计量大多数分布在0到3之间,对于大于3的情况,则取1为其归一化结果。位信息熵也采取同样的做法。

表1 特征值和归一化方法 Tab. 1 Flag value and normalization method

4 实验评估 4.1 实验环境

内网通过网关连接至Internet,流量采集程序部署在网关上,这样做可以采集到该局域网内所有的网络流量。对于网关所捕获的网络流量,由一台处理机对其进行识别和分类处理。系统网络拓扑如图 3所示。

图3 系统网络拓扑 Fig. 3 Topology of system network

4.2 流量识别的评价标准

本文将使用召回率 (recall) 和准确率 (accuracy) 两项指标来评价识别结果。计算方法如下:

$ \begin{array}{l} \;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;recall = TP/\left( {TP + FN} \right), \\ accuracy = \left( {TP + TN} \right)/\left( {TP + FN + FP + TN} \right)。\end{array} $

其中,TP为被分类器正确地划分为正例的实例数,TN为被分类器正确地划分为负例的实例数,FP为被分类器错误地划分为正例的实例数,FN为被分类器错误地划分为负例的实例数。

4.3 基于特征匹配识别的实验评估

基于特征匹配的Tor匿名通信识别方法分为:基于Meek TLS静态特征的流量过滤和基于Meek流动态特征的流量识别两个步骤。

算法首先通过基于Meek静态特征的流量过滤后,目的是排除非Meek流的干扰,这样就只需对少数剩下的流量再做进一步的识别判断。因为该过滤方法无法对使用相应版本的Firefox浏览器访问Amazon等云服务时所产生的TLS流和Tor-Meek流进行有效区分,因此需要进一步采用基于Meek流动态特征的流量识别步骤。该步骤的核心是检测一条待识别流中是否含有Meek的轮询请求机制特征。为了验证流动态特征的特异性,本文对捕获的所有TLS流都进行了测试,包括通过Meek TLS静态特征过滤的TLS流和未能通过过滤的TLS流。实验发现,除Meek流之外,任何其他的TLS流都未能满足轮询请求机制的识别条件。

4.3.1 不同长度流的识别准确率

本组实验的目的是考察不同长度的Meek流的识别效果。分别将Meek流按长度分为小于40个包、40~99个包、100~199个包、200~299个包、300~399个包和大于400个包的Meek流。本组实验样本中一共包含522条IPv4的Meek流和5 217条IPv6的Meek流。

分别计算以Meek流发起第1到第11次轮询请求机制作为识别准则的准确率。例如,以发起第3次轮询请求机制作为判断标准,那么,如果一条待识别的Meek流发起轮询请求机制并增长到第3次,则认定该条流为Meek流。计算结果如图 45所示。

图4 不同长度IPv6流识别的准确率 Fig. 4 Accuracy rate of IPv6's flow recognition

图5 不同长度IPv4流的识别结果的准确率 Fig. 5 Accuracy rate of IPv4's flow recognition

当判定准则设定的轮询次数越多时,就会有更多的Meek流被漏报,因此准确率就越低。对于相同的轮询次数,对于长度小于40个包的Meek流,产生的轮询请求机制次数很少,其中,IPv4环境下为0;。对于长度大于200的Meek流,有90%以上都发起了第2次轮询请求机制。而且长度越长的Meek流,所发起轮询请求机制的次数越多,识别的准确率越高。

4.3.2 不同Tor Browser版本的识别准确率

本组实验的目的是考察不同Tor Browser版本以及不同Meek网桥的Meek流的识别效果。实验数据包含Tor Browser 4.2 Meek-Amazon、Tor Browser 4.2 Meek-Azure、Tor Browser 5.2 Meek-Azure、Tor Browser 5.5 Meek-Azure、Tor Browser 6.0 Meek-Azure的Meek流,共5 739条。计算方式与4.3.1节相同,计算结果见如图 6

图6 不同Tor Browser版本识别的准确率 Fig. 6 Accuracy rate of tor's different versions

通过实验结果可以发现:对于Tor Browser 5.X和6.X版本的Meek流,有90%以上都发起了第2次轮询请求机制。对于Tor Browser 4.X版本的Meek流相对较低,有70%以上发起了第2次轮询请求机制,分析其原因,主要是在实验时Tor Browser 4.X版本过相对较旧,因而连接状态不稳定,产生了大量的重传包对识别效果造成了影响。

4.3.3 基于特征匹配的识别准确率

通过以上2组实验的结果可知:对于长度较短 (小于40个包) 的Meek流,一般检测不到Meek的轮询请求机制;对于长度大于200个包的Meek流,有95%以上可以检测到第2次Meek的轮询请求机制。结合Meek的连接特性来看,可以认为对于长度过短的Meek流是无效的Meek流,因为即便该TLS流是Meek流,但它不可能通过40个以内的数据包完成Tor连接的建立过程,更不能进行后续访问Tor的操作,所以对长度过短的TLS可以直接排除。在排除长度小于40个包的流之后,对不同的Tor Browser版本识别的准确率如图 7所示。

图7 基于特征匹配识别方法的准确率 Fig. 7 Accuracy rate of flow features matching

4.3.4 实时性分析

基于流特征的识别的计算主要集中在对轮询请求机制的判断上。为评价该方法的识别时间性能,本文对平均长度为314个包的SSL流执行1×105次轮询请求机制判断,在除去IO操作的耗时后,共耗时706 ms。基于流特征的识别方法具有较好的实时性。

4.4 基于SVM识别的实验评估

基于特征匹配的识别算法容易受到版本变化与更新的影响,本文第3节提出基于统计特征的分类算法可以有效解决该问题。基于SVM的Tor匿名通信识别的关键部分是SVM分类器的构造和特征值的选取。对于SVM分类器,使用LibSVM工具包,选择C-SVC,线性核函数。之后对于惩罚系数c的选择,使用不同的值进行多次训练和检测,根据检测结果选取最优解,c按2的指数次幂进行取值,变化范围从20到210

4.4.1 分片大小对识别准确率的影响

在基于Meek流分片的模型中,分片的大小将对识别的结果将产生直接的影响,分片过大或者过小,都会使识别的准确率下降。为了选择最佳的分片大小,需要对不同的分片大小分别进行了测试。本次实验使用1 000条Meek流和200条非Meek流作为训练样本,分片大小分别取20、30、40和50个数据包,之后对不同的分片大小和惩罚系数c的组合分别进行多次训练和检测。检测结果见表 2

表2 分片大小实验的准确率 Tab. 2 Accuracy rate of fragmentation sizes

由检测结果可以看出,识别的准确率随着分片大小从20增加到50是依次递增的,当分片大小为40时,识别的准确率可以达到97.5%(c=32或128时),当分片大小为50时,识别的准确率可以达到99.4%。因此,基于Meek流分片模型的识别方法,对于Meek流的识别有较高的准确率。

4.4.2 特征组合的选取对识别准确率的影响

另外一个需要关注的问题是特征组合的选取。下面将通过实验对4类特征不同的组合进行评估。测试方法同第4.4.1节,选择不同的特征值和惩罚系数c的组合进行多次训练和检测,根据检测结果选择最佳的特征值和惩罚系数c的组合。

本次实验使用与分片大小实验中相同的训练和检测样本,分片大小取40。本次实验中选用不同的特征类型的组合分别进行多次训练和检测,其中,A代表长度及个数特征,B代表接收发送序列特征,C代表长度方差特征,D代表长度熵特征。例如,A+B即为长度及个数特征和接收发送序列特征的组合。检测结果见表 3

表3 特征组合实验的准确率 Tab. 3 Accuracy rate of feature combinations

由检测结果可以看出,当选用长度及个数特征+接收发送序列特征+长度熵特征的组合时,分片大小为40的准确率可以由之前的97.5%上升到最高99.5%(c=32, 128, 512, 1024时)。因此在本文所以出的基于SVM的识别模型中可以选用长度及个数特征、接收发送序列特征和长度熵特征作为Meek分片的特征值,以便获得更好识别准确率和识别效率。

4.4.3 参数优化后的识别准确率

根据以上两组实验的检测结果可以得知:选用分片大小40,长度及个数特征、接收发送序列特征和长度熵特征3类特征作来构造分类器。对不同的Tor Browser版本的Meek流分别进行了大量的检测,识别的准确率均可以达到97%以上,见表 4,识别的召回率99%以上,结果见表 5

表4 参数优化的识别准确率 Tab. 4 Accuracy rate of optimized identification

表5 参数优化的识别的召回率 Tab. 5 Recall rate of optimized identification

4.4.4 实时性分析

基于流特征的识别的计算主要集中在对轮询请求机制的判断上。为评价基于SVM的识别方法的识别时间性能,本文对平均长度为316个包的SSL流执行1×105次特征提取,在除去IO操作的耗时后,共耗时6 236 ms。分类需要159 ms,可见基于SVM的识别方法具有良好的时间性能。

5 结论

自从Tor Browser 4.0版引入了Meek流量传输插件以来,Tor得到了进一步的混淆和伪装,有效地抵御网络审查和流量分析攻击。本文主要针对Tor-Meek匿名通信开展分析和研究。阐述了Tor和Meek的工作原理,包括Meek使用的前置域名技术和基于浏览器代理的加密技术等。并通过对Meek进行流量特征分析,总结提出了7个Tor-Meek的流量特征,包括Meek的单一有序连接特征、TLS Client Hello静态特征、网络空闲时的轮询请求机制动态特征等以及4类16种统计特征。在此基础上,本文提出了基于特征匹配的Tor匿名通信识别方法和基于SVM的Tor匿名通信识别方法。实验结果表明,以上方法均可有效识别基于云流量混淆Meek的Tor匿名通信流量,且具有较高的准确率、召回率和实时性能。

未来可在识别Tor-Meek匿名通信流量的基础之上,进一步对其通信的内容进行分类和识别,以便对Tor匿名通信流量实施更加有效的监管。此外,Tor除了使用了Meek网桥技术之外,还有多种其他的网桥技术。如何对其他网桥技术实现有效的识别,本文尚未做出研究和讨论,故可以对Tor的其他网桥技术开研究和分析。

参考文献
[1]
Pfitzmann A, K hntopp M. Anonymity, unobservability, and pseudonymity-A proposal for terminology[M]. Heidelberg: Springer, 2001, 1-9.
[2]
Serjantov A. Anonymizing censorship resistant systems[M]. Heidelberg: Springer-Velag, 2002, 111-120.
[3]
Reed M G, Syverson P F, Goldschlag D M, et al. Anonymous connections and onion routing[J]. IEEE Journal on Selected Areas in Communication, 1998, 16(4): 482-494. DOI:10.1109/49.668972
[4]
Danezis G, Dingledine R, Mathewson N.Mixminion:Design of a type Ⅲ anonymous remailer protocol[C]//Proceedings of the 2003 IEEE Symposium on Security and Privacy.Oakland, California:IEEE, 2003:2-15.
[5]
Reiter M K, Rubin A D. Crowds:Anonymity for web transactions[J]. ACM Transactions on Information and System Security, 1998, 1(1): 62-92.
[6]
Chaum D. The dining cryptographer's problem:Unconditional sender and recipient untraceability[J]. Journal of Cryptology, 1988, 1(1): 65-75.
[7]
Sherwood R, Bhattacharjee B, Srinivasan A. P5:A protocol for scalable anonymous communication[J]. Journal of Computer Security, 2005, 13(6): 839-876. DOI:10.3233/JCS-2005-13602
[8]
Zhao Guofeng, Ji Chaoming, Xu Chuan. Survey of techniques for Internet traffic identification[J]. Journal of Chinese Computer Systems, 2010, 31(8): 1514-1520. [赵国锋, 吉朝明, 徐川. Internet流量识别技术研究[J]. 小型微型计算机系统, 2010, 31(8): 1514-1520.]
[9]
Dingledine R, Mathewson N, Syverson P. Tor:The second-generation onion router[C].Conference on Usenix Security Symposium, USENIX Association, 2004:21-21.
[10]
Tor Project[EB/OL].[2016-04-05] https://metrics.torproject.org.
[11]
He Gaofeng, Yang Ming, Luo Junzhou, et al. Online identification of Tor anonymous communication traffic[J]. Journal of Software, 2013, 24(3): 540-556. [何高峰, 杨明, 罗军舟, 等. Tor匿名通信流量在线识别方法[J]. 软件学报, 2013, 24(3): 540-556.]
[12]
Tor's documentation[EB/OL].[2016-04-05].https://www.torproject.org/docs/documentation.html.en.
[13]
Dingledine R, Mathewson N.Tor's protocol specifications[EB/OL].[2016-04-05].http://tor.eff.org/cvs/doc/tor-spec.txt, 2008.
[14]
Tor's protocol specifications[EB/OL].[2016-04-05].https://gitweb.torproject.org/torspec.git/tree/attic/bridges-spec.txt.
[15]
doc_meek[EB/OL].[2016-04-05].Tor bug tracker & Wiki.https://trac.torproject.org/projects/tor/wiki/doc/meek.
[16]
Fifield D, Lan C, Hynes R, et al. Blocking-resistant communication through domain fronting[J]. Proceedings on Privacy Enhancing Technologies, 2015, 2015(2): 1-19. DOI:10.1515/popets-2015-0025
[17]
Chaum D. Untraceable electronic mail, return addresses, and digital pseudonyms[J]. Communications of the ACM, 1981, 24(2): 84-88. DOI:10.1145/358549.358563
[18]
netMarketShare[EB/OL].[2016-04-05].http://www.netmarketshare.com/.
[19]
Vapnik V N. The nature of statistical learning theory[M]. New York: Springer-Verlag, 1995, 112-268.