According to the requirements of the EU GDPR ( EU General Data Protection Regulation ). We need to inform you of some matters,please click here.

MENU

[转载]一些代理协议的简单统计分析(认真脸)

2018-01-20 • Nico的日常生活

Posted by Break wa11

这个文章不是什么高深的技术帖子,只是个统计分析,也是为了大家都尽可能看懂而写

这里的分析也不是分析什么高大上的东西,只做一个很简单的事情,就是统计,然后画图。在这两年间居然没有人做这个工作,所以我想我还是简单做一做,给大家对这些代理协议来一个直观的感受。

那统计什么呢?通过抓包记录,把每个数据包的大小以图形的形式表示出来

以下为示例图(图1,请放大仔细看):

这个图,横坐标是包的大小,最左边是0,最右边是1447,最下方有个标尺,一小格就表示10,一大格就是100,纵坐标是这个包发送了的个数的比例,数量越多就越长,以最长的那个作为100%高度。同一根同时存在紫色和绿色,其中紫色的是上传,绿色的是下载,例如这个图里面,最左边第一个小格的中间位置(横坐标是6),绿色的高度是大约是紫色的高度的2/3左右,即大小为6的包,下载的数量是上传数量的2/3左右。

上面这个图可以看出,包的分布非常的稀疏,大多数位置都是0,而且大多数的包都集中在特定的位置上(贫富差距非常大),导致高的柱子高度特别的高,尤其是上传方向上。那么这些特别长的柱子可以作为特征吗?不,并不一定,并不是长的就有用,但特别短的就一定用不上。特别长的那些可能只是你访问不同的网站而产生的不同的特征,并不一定有代表性。

图2

以上这个是另一个例子,你发现特别长的那根的位置很明显的不一样了,嗯,没错,这个其实用的是另一个加密且访问不同的网站的结果。那么,应该怎么找特征呢?右边的包先不用看,看左边的,即尺寸较小的包,前一张图最小尺寸的包是6,而这一张的是18,这两数值有什么作用吗?首先,这两数的差是12,看第一张图的横坐标44的地方,有根较高的柱子,然后52的地方有根稍矮一点的,那这两个数分别加上12,得到56和64,对照看看第二张图这两个位置,正好也有两根很高的柱子,这种吻合说明的是这两个应该是跑的同一种协议,而第二个在第一个的基础上多了12字节的偏移。而事实上,这是个代理协议,代理的流量是访问twitter/youtube这类https(TLS)站产生的。而通过抓取实际的网站访问流量再画成图,我们可以发现(此图就不提供了),前面图1相对于实际流量有6字节的偏移,图2相对于实际流量有18字节的偏移,而这个偏移正好等于图上的最左边的包的大小,而实际的流量并不存在6或18这根柱子,因为不可能在0的地方有数据包。于是,这能得到两个结论:1,这里的6或18字节偏移应该是这个代理协议在每个数据包的附加数据(表示包的长度和数据效验等);2,这里的6或18字节的数据包一定是被代理的协议里面不存在的包,是一个有特殊功能的包,这个包将是这个协议的最明显的特征。

以上两图就简单分析到这里了,揭晓答案吧,第一个图是V2Ray使用 vmess协议 + aes-128-cfb加密的记录,第二个图是V2Ray使用 vmess协议 + aes-128-gcm加密的记录。根据协议文档,第一个是有2字节的数据包长度及4字节的校验,正好6字节的附加长度,第二个是2字节的数据包长度加上16字节的tag作为校验,正好18字节的附加长度。也就是说我们可以通过记录https站的数据包分布与其作对比,根据偏移的字节数知道这个连接使用的是什么加密,以及实际上在浏览什么网站。

我们再来看一个协议的统计图(图3)

这一个是firefly代理的统计图,但同样是访问https网站记录下的,在图上你能看到分布比前一个还要稀疏,但非常有趣的一点是TLS的特征在这里被抹掉了,但这个代理我没有找到具体的协议文档描述,我也没空去看代码分析这些包具体对应什么,这个就没法详细说了。但我们可以知道这个代理的协议是一个上下行不对称的协议。什么叫上下行不对称?你对比一下前两图,较高的柱子往往是两种颜色同时存在,说明同一类型的数据包,上传和下载是一样大的,可以猜测出使用了一样的数据结构。而这个图,神奇般地没有一根柱子同时存在两种颜色,也许是统计数据还不够多吧,但足够说明上传和下载的数据包格式应该是不一样的,不对称的。而非对称协议很可能表明它是个使用一个TCP连接承载多个TCP连接的协议。

接下来,我们来看看大名鼎鼎的Tor项目的混淆插件obfs4的统计图4(使用的是ptproxy项目的封装,作者gumblex)

一眼看过去,显著地和前面几个不一样,数据包分散地分布在不同大小的地方,可以想象obfs4连接的时候,就产生随机大小的包,以致于非常难通过分析知道这个连接可能在发什么样的数据,从抗分析上会明显强于之前和协议(但安装过程如此复杂麻烦实在不清真)。但是直觉告诉我这些高的柱子的位置很奇怪,于是我把客户端和服务端都关了重开,重新统计得到一张新的统计图,同时把两张图重叠一下得到如下图5:

重叠在下方那个是图4,上半是访问http站(不是https/TLS)产生的流量的统计图。你会发现居然还是在相同的地方出现了高高的柱子,尽管很分散,但位置竟然是固定的,且与你访问什么内容无关,而且是非常明显的上下行对称的协议(所有高的柱子都同时存在两种颜色),这让我非常的不解。从obfs4的文档上看,它确实有随机填充的字段,而且随机范围从0到8096,但是由于这里只统计了小于1448的数据包,大于的在这里做了一次过滤,没有在图上画出来。既然是随机,那居然只分布在如此少且相对集中的地方让我感到这很奇怪,因为这些固定的地方活生生成为了obfs4独有的特征。与此同时,我们能解释一个事实,就是obfs4为什么明显慢于其它的代理,因为它的随机填充的范围实在是太大,几百字节的包填充一下平均4千字节,导致会多出两三个数据包要发送,速度起码慢一半,而事实上确实如此。这里故意没画大的数据包,因为如果画上去了,前面这些柱子将会短得几乎看不见,目前貌似也只有obfs4会这样发包,超过90%的包都等于MSS大小(注:一个等于MSS大小的包会连同它后面的一个包(不管它是不是只有1字节)整体作为一个包统计)。如果以上内容核实,那么obfs4就是可以被识别的,但目前数据量不足,还需要多建立几个服务端测试(安装好烦啊)。我曾经和obfs4的作者Yawning Angel沟通过,他确认了obfs4确实存在问题,有新的混淆插件的计划。

最后,我们来看看SSR的auth_aes128_md5协议(不带混淆)的统计图6(使用C# 4.1.5版本客户端)

这明显得不能更明显地和前面的都不一样,可以清楚地看出来,这个的数据包分布均匀得多,也不存在哪个尺寸的包特别多,且不管上传还是下载都是如此(注,这个图是比例图,看上去似乎到处都很高,但是前面图1至图3最高点实际值达到几百,而此图最高的柱子高度是13,若把此图放在图1至图3使用相同的坐标系显示那么会显得很矮,矮得几乎看不见,高度仅1至2个像素,高度比例非常低,变成应该被忽视的部分)。这个特性有什么用呢?这个特性会导致无法通过特征分析知道你在浏览什么网站,也难以与发送随机数据包的协议区分开,更无法知道到底上下行对不对称,总之,这些数据包的分布导致大部分的统计分析失效,同时也会导致DPI或模式识别失效。由于分布均匀的特性,如果与其它具有明显特征的协议(如同时开一个http/https站)在同一个端口传输,那么外部特征将是那个有明显特征的协议,因为SSR的auth_aes128_md5协议本身的平均分布特性不会影响原来的特征分布,关注点就会被成功转移,将是以上几个协议里最难识别的协议实现(臭不要脸地)。

一个小插曲,有个网友做了个实验,使用auth_aes128_md5协议,不带混淆,不带加密,直接祼跑超过了80G流量,还是啥事都没发生。有没有人有兴趣用origin协议不带加密试试看?实验过的告诉我一声什么结果。

タグ: -
アーカイブに戻る QRコード
この記事のQRコード
報酬のためのQRコード
0:00