一些代理协议的统计分析

楼主临近毕业，又要开始找实习了，在github上也只是发表过为数不多的几个项目。再加上github主要还是代码托管，觉得还是写点博客跟大家讨论来得有意思

码字不易 转载请注明出处 转载请注明出处  CSDN yinwei4163(BreakWa11)

首先申明 
本文不是什么很难理解的帖子，只是个统计分析。
这里的分析也不是分析什么高大上的东西，只做一个很简单的事情，就是统计，然后画图。
那统计什么呢？通过抓包记录，把每个数据包的大小以图形的形式表示出来

以下为示例图（图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字节）整体作为一个包统计）。

最后，我们来看看auth_aes128_md5协议（不带混淆）的统计图6

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