Tuesday, April 11, 2017

无题

这里准备写一下最近的感想,不说技术方面的。

最近发生了一堆事情,尤其上星期我状态惯例很差。而就在这个时候,各位dalao发了两篇文章,都说到安全性。

反正我是很不懂为什么要安全性啦,好比面对同一个围棋局面,有的人认为要抢实地,有的人认为要厚势,有的人要摆大空模样,但这不重要,重要的是,无法说服对方同意自己的看法。而唯一说服对方可能性的办法,就是和他下,下多少把赢多少把,让对方输的怀疑人生。

而且,最大的问题是,他们的看法我认真看过几遍,都和我的看法很不一样,那这当然了,要是和我的看法一样,就可能直接和我合作了,怎么还写这种文章呢,而且丝毫看不到任何说服他们任何一个的可能性。当然,反过来看,他们也不存在说服我的可能性。

那这问题不就来了么,为什么都认为自己的是对的?而且为什么都不能说服对方?

举个例子,还是拿围棋。比如死活,这一片棋,说多不多,说少也不少,有4、5个,还没活,正遇到攻击,那怎么办?当然是做活搜刮对方的目数啊。当然,大部分情况下这样都是对的,但如果纵观全局,如果弃掉这4、5子却能在外面捞到比这更多的目数呢?理论上当然可以,但谁能看出来保证能捞到更多呢?你得有一个远超局部的眼光,才能看出弃子后的变化。

所以,真正的问题是什么?没错,正是看问题所在的局部。每个人所在的局部来看,结论都是对的,问题是,大家争论问题的时候,都没有讨论这个“局部”的范围到底是什么。而之所以他们的看法和我的很不一样,正是这个“局部”的区域并不相同。

但是,更好玩的是,如果真要讨论这个“局部”本身,那么结果会是相互否决对方的“局部”的合理性。

也就是说,除了他们的“局部”能重叠的地方,其它地方是不可能讨论下去的,讨论不过是浪费时间。

但是,这些问题偏偏是最不应该闭门造车,但事实上看来却不得不先闭门造车,为什么?因为你都没有把车造出来,拿什么来说服对方?码农最喜欢的一句话是"talk is cheap, show me the code"。这个是从我2015年8月底学会的,自此之后我再也不只发结论,只发相关的资料和代码,结论本身一点也不重要,更重要的是结论本身会影响很多人的利益,为了自身利益那些人怎么可能会让步?

最后结果是只能自己一个人研究,但自己研究很可能会出问题,除非自己就有足够的眼光。当然这是很困难的,但可以通过不停地研究不断进行修正,所以我自己并未停止研究,最近又新发现了几个从未曾想到的问题。

自己一个人研究非常的孤独,不理解你又不熟悉你的人会批判你,你熟悉的人却没有理解你的,而你不熟悉的人你没办法知道他理不理解你。这种情形有点像我小学的时候,没有女生找我玩,当然我更不会去找男生玩,不过我早已习惯。后来我也成了班里唯一一个升重点中学且为重点实验班的女生。当然,我也是因为去了那个班才知道牛人如此多,尤其是数学考试几乎总是比其它班平均分高出20+分,卷面分要是拿不到90%那就是在班里倒数几名的范围了。哪次要是平均分比第二名的班高出的分数小于20分可是得被班主任(数学老师)狠狠补课的,各种变态般的计算题证明题。到中考,依然是一堆人140+分(总分150),拿140+分简直像是必须的。压力这么大的环境我都不记得我是怎么活过来的。

所以,在实在压力大得不行的时候,怎么释放心理压力呢?我的方法太简单了,哭一会就好,但我是在4个月前第一次试过几乎哭了一天不停,最麻烦的是在别人面前还要装着没事,笑着聊天。挺有意思是事是这被很多人说“玻璃心”,那我反问一句,你们这些没有“玻璃心”的,是不是遇到点困难就放弃,所以从来不需要哭呢,那你们很"man"啊,你们努力过些什么了?那这些人当然会说:“上个网要努力什么?关我什么事?”,没错,因为这不需要成本,骂人,伤害别人,在网上除了花点时间打字,啥都不需要,所以盗版有理,破解王道,免流标配,只要不花钱,花点时间不算什么,尊重别人是什么鬼,我爱干什么就干什么,不是说言论自由吗?你管我说什么呢?<==持有以上观点的人,我都直接拉黑。

那回到文章一开始的问题,如果非要讨论安全性,那让我推荐一个加密方式的话,我推荐rc4-md5,哪个速度快用哪个(如果你机器上chacha20更快那就用这个,至于AEAD的没必要,因为这个虽然增加了安全性,但在另一个方面下降了(不是加解密时间),我不推荐,所以SSR里不会有AEAD),如果你用的是SSR的auth_aes128_*协议,那就大胆用none吧,至少目前看来不需要加密,不需要这种安全性。但千万不能直接用origin协议不加密,因为已经能准确多次重现打开特定网站会被立即封锁。那如果你非得要安全性怎么办?在PC上很简单的,只要开OpenVPN,开最高级别的加密和交换密钥方式(用ECC系列加上aes-256-gcm),以SSR做二级代理走TCP,问题就解决了。

有人把抗识别定义为以下两点:
1.观察一段数据流量,是否能判别这是一个代理协议的流量
2.对于一个仅暴露出 TCP 端口的黑箱,能否判断这个端口提供了代理服务
> 最后得出的结论一:最新的 shadowsocks 已经能满足抗识别的两个要求
这我当然是不同意的,不管1还是2均不满足,2还依赖于实际的服务端必须是ss-libev以及必须是AEAD加密。而且事实上,不会只使用1或2,而是组合使用,而且手段还不止这两种。
> 结论二:而使用 HTTPS,观察者无法判断这是一个 HTTPS 代理还是 HTTPS Web 服务器
这我同样是不同意的,可以识别,即使拿同一个端口,一会儿跑实际的https,一会儿跑https proxy,两者是不一样的,能知道什么时候是https proxy。甚至强如obfs4proxy,我都可以轻松地仅从流量记录看出来协议的一些关键信息,例如协议的RTT,有人看过文档和我说过RTT是3,但我一直想验证一下,又不想看代码,于是尝试看了一下记录,竟然比我想象中还要简单地看出来。
那为什么他认为满足而我认为不满足?其实就是所用的识别手段范围不一样,但其实很难因为自己的识别手段办不到而断定不能识别,好比某个猜想你证明不出来,你也找不到反例,于是你也无法推翻它,也无法肯定它一样。我都不会武断的认为SSR如今无法识别,但能肯定的是还有做得更好的空间。

那我怎么看“抗识别”呢?我的看法依然完全不一样,我并不这样定义,我把这个定义写成了一篇文章。而SSR达到了我的期望了吗?还没有,我头痛了几个月在研究,新的协议还没看诞生,还有好多难点。但大家造轮子好像造得很轻松的样子呢,那当然就是目标不同导致的,大家觉得很轻松,我觉得很困难,因为我还要解决几个数学问题。

看着blogger里囤着的好几篇一直在draft状态的文章,一声叹息,等吧,等我什么时候能解决这个问题再说,我继续折腾我自己的事去了。

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

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