Saturday, April 1, 2017

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

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

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

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

以下为示例图(图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协议不带加密试试看?实验过的告诉我一声什么结果。

我一本正经地胡说八道完了,以上所有内容其实都是骗大家的,愚人节快乐。

22 comments:

  1. 我就是那个跑了80g的


    顺便表个白:今好きになる嘤嘤嘤

    ReplyDelete
    Replies
    1. This comment has been removed by the author.

      Delete
  2. 我就喜欢这样的!技术不成熟!又骗人!协议又不好用的!

    ReplyDelete
  3. 我就喜欢听别人一本正经的胡说八道

    ReplyDelete
  4. This comment has been removed by the author.

    ReplyDelete
  5. 这个点根据时差还来得及表个白(* ̄3 ̄)╭♡

    ReplyDelete
  6. 一本正經從頭看完XD
    然後才想起來昨天是愚人節阿,哈哈哈哈,愚人節快樂

    ReplyDelete
  7. 博主犀利~一天鄙视你又追着你喷的非奸即盗,不然他们闲的蛋疼么?但愿公道长在人心。

    ReplyDelete
  8. 厉害了破娃酱,虽然看不懂,但爱你,更爱你搞的协议

    ReplyDelete
  9. 这么牛逼的小姐姐不推倒还有天理吗? 默默更新服务器端去了

    ReplyDelete
  10. Anonymous21/4/17 13:01

    这么平均尺寸的包本身也是一种特征吧。。哎,反正总感觉目前的协议或者加密只要用的人多了,总能从统计学上分析出数据包特征。如果能根据每个人的机器码或者IP啥的生成各自不同的数据包分布,是不是会好点。

    ReplyDelete
  11. Anonymous10/6/17 05:39

    萤火虫翻墙代理(Firefly-proxy)利用Tor 的meek插件来实现翻墙目的的软件

    基于Meek的Tor匿名通信识别方法的研究和实现--《北京交通大学》2016 ...
    cdmd.cnki.com.cn/Article/CDMD-10004-1016120870.htm

    doc/meek – Tor Bug Tracker & Wiki
    https://trac.torproject.org/projects/tor/wiki/doc/meek

    ReplyDelete
    Replies
    1. 内部肯定还有一层协议,是一个连接承载多个连接的对等协议

      Delete
  12. 支持breakwall20/6/17 05:15

    obfs4那些作者水平太次了,坑人都不出一聲的。軟件寫好了能不開源就不開源,閉源軟件可以加大被分析難度,延長軟件生命期,博主是很出色的

    ReplyDelete
    Replies
    1. 你这句话是错的,OBFS4是开源的

      Delete
  13. 我竟然一本正经地的看完了

    ReplyDelete
  14. Anonymous19/7/17 15:07

    Obfs4基本上基于scramblesuit,所以应该是第一次server初始化data-dir时决定其特征。
    可以试试看重新初始化obfsproxy用的data-dir会不会有不同的特征。
    不过除了包大小外,包时序也可能被作为判断条件。
    obfsproxy貌似从obfs2开始就对这块有paper。

    顺带,这个特征分析基本验证了混淆应该单独做一层,防止某种混淆协议有特征被检测。

    ReplyDelete
  15. Anonymous20/7/17 22:04

    这不就是PAPR么,学过通信原理的都知道好的信道编码要峰均比小,看上去最好像白噪声,随机序列,扩频因子要大,比如CDMA/WCDMA系统空口编码和调制方式。
    internet上包大小是不是也服从高斯白噪声分布呢,不知道,没大数据统计。不过一般交换机都会以逼近MTU组包,猜测大包居多。所以如何伪装最佳,还是是要看背景流量特征(错落、平坦都是特征)。

    ReplyDelete
  16. 假装很认真的看完了。

    ReplyDelete
  17. 谢谢BreakWa11酱。我现在主要是我个人在科学上网,请问直接SSH -D和用SS/SSR会有显著区别么?我觉得SS/SSR最近似乎有些不稳定,但是SSH -D从来没有连不上过。

    ReplyDelete