TOR与GFW的PK（5） ————被抛弃的Dust

TOR与GFW的PK（5）
                                 ————被抛弃的Dust

话说最近的封锁真的是越来越厉害了，翻墙工具们纷纷倒下，不过Tor的MEEK插件和obfs4网桥（经本人测试，默认集成的网桥已经被屏蔽了，请去这里[1]获取可用网桥）依旧坚挺。对于Tor团队的辛勤工作，本幽灵在此表示感谢！

Tor有MEEK，obfs4，obfs3，FTE，scrambleSuit这些整合在Tor Bowser Bundle里的插件，我在之前的系列里已经一一介绍过了。不过其实Tor团队还开发了三种流量混淆插件：StegoTorus，SkypeMorph，Dust，但是后来不知为什么都被弃用了。其中StegoTorus和SkypeMorph插件已经从2012年开始就停止更新了，而Dust却一直在github上持续更新着[2]。我看了一下Dust的设计文档，觉得提供了一种不错的翻墙思路，特此进行详细介绍。

在正式开始之前，我想问大家一个问题：对翻墙工具应该提什么样的要求？

”翻墙工具应该设置简便，用户友好，最好能做到一键翻墙！“

幽灵评价：没错，如果翻墙工具的设置太过复杂，那么大部分人就都会放弃翻墙的，不利于发展翻墙党党员：）

”翻墙工具应该尽可能免费，即使要收费，也要把价格控制在一个合理的范围内，最好尽可能利用公共免费服务器。“

幽灵评价：没错，过高的价格也会挡住大多数人，况且大部分人是不愿意付钱的，而且说实在的谁都不该为这堵不该存在的墙付钱。

”翻墙工具最重要的是要足够坚挺，不然三天两头失效谁也受不了“。

幽灵评价：这是最重要的一点，通常来说翻墙工具的坚挺程度主要取决于两点：1，翻墙工具的工作原理；2，翻墙工具的流行程度。越流行的翻墙工具，越容易引起GFW的注意；不过只要在设计时就考虑到GFW的封锁并且设置了相应的对策，那么GFW多数情况下就只能干瞪眼了。

”翻墙速度必须要快，至少也要看youtube720P视频不费力吧！“

幽灵评价：这一点恐怕是大部分翻墙党的默认要求了，我每天都能在G+上看到一群速度党们在比速度。不过我想说的是，除非你是个高清视频发烧友或者重度下载党，否则根本没有任何追求速度的必要，只要能正常浏览网页即可。事实上速度是最不重要的一点，而且高带宽流量是很容易引起GFW的注意的。

免费（或者是学生党也能接受的低价格），坚挺，能正常浏览网页的速度，设置简便，这应该是一个优秀的翻墙软件所应有的特质。

而Dust就是为了其中最重要的特质——坚挺而生的。GFW对于翻墙工具的封锁手段有：人工检查大流量所对应的IP，一旦发现是提供翻墙服务的，就封IP（所以说单纯追求速度不是一个好习惯）；自动检测协议指纹，发现匹配的就自动封锁（OPENVPN就是这么死的）[3]；主动探测攻击[4]；人工搜索免费的翻墙服务然后进行封锁等，其中特征检测（自动检测协议指纹）被越来越频繁的使用，成了一个难对付的敌人（IP封锁成本高且总是滞后，但特征检测却能做到自动即时封锁）。

Dust：”别害怕，有我呢！我就是专门对付这该死的特征检测的！“

”说起来协议指纹识别主要从这几个方面入手：经过协议处理之后的数据包长度，发送时间间隔，结构，以及最重要的：明文的handshake过程。遥想当年曾经风光一时的HTTPS代理，SSH，OPENVPN还有VPNGATE都是死在了handshake上，准确的来说是死在了公钥交换这一步上：一个个全都要求证书，结果就是证书被GFW嗅探出来，然后对应的服务器全部都被一锅端了[5]。就算是设置成不要证书的，本身的协议指纹还是很明显，结果就都悲剧了。“

”除此之外，绝大部分翻墙工具在工作时都会和远程服务器建立长时间的TCP连接（shadowsocks，Tor，SSH，大部分VPN协议等都是如此），而这样就看上去很像是翻墙的了：如果是正常浏览没有被墙的国外网站，那么先是建立TCP连接（前面的DNS查询过程就先略过了），然后再建立HTTP连接，等到网页很快加载好了之后TCP连接就会关闭[6]。也就是说，不会有长时间的TCP连接的。那么那些长时间的TCP连接就有很大可能是翻墙的了。”

而Dust提供了不错的对策[7]：首先，Dust协议会对数据包进行随机的填充处理，这样就会产生随机长度的数据包，从而使得GFW无法从数据包长度这一点下手检测；

然后，Dust使用UDP而不是TCP传输数据包！“UDP？这可是无连接的不可靠协议啊，那难道不进行handshake啦？那么怎么进行公钥交换啊，客户端和服务器端怎么协商会话金钥啊？要知道handshake过程必须是可靠的啊，这一过程中一个数据包都不能丢，要不然就无法完成handshake了好吧？”

“公钥交换还是要进行的，不过的确没有handshake过程了。Dust协议是这样解决公钥交换问题的：首先，Dust服务器要准备一对id-secret（意思就是id和secret是对应的，一个加密，另一个就能解密，当然这里使用的是非对称加密算法），安全的存储起来，后面要用；然后向未知的客户端们发送邀请数据包，邀请内容有：本服务器IP地址，端口，服务器公钥和id。邀请可以被自行设置的密码加密，当然明文也不要紧。然后服务器的操作者就想办法把邀请数据包散布出去（如果加密了，还要带上密码），或者广播，或者以其他什么方式把数据包递到客户端手中。

然后客户端根据收到的邀请，向服务器端发送一个介绍数据包：用从邀请中收到的id对客户端公钥进行加密，在数据包的未加密部分放置部分id。服务器端收到之后就根据未加密部分放置的部分id进行查询，找到对应的secret，然后解密得到客户端公钥，并将公钥放到已知客户端列表中（同时附上客户端IP地址和端口）。这样一来，公钥交换就完成了！”

“接下来客户端和服务器端都用这两个公钥算出会话金钥，数据传递过程就开始了。因为是UDP连接，所以就没有客户端和服务器端的连接（虚电路）了，服务器端只能通过一种别扭的方式接收数据：每当接收到一个数据包时，服务器就将数据包的源IP地址和端口与已知客户端列表进行比对，如果对上了，那就用对应的会话金钥解密；如果没对上，就认为这是介绍数据包然后尝试用对应的secret解密。”

这一过程中的id是随机生成的，而且是一次性的，防止被GFW识别。使用的加密算法也都是很可靠的，暴力破解不靠谱。

不过其实最难办的还是将邀请数据包分发出去这一步，似乎没有什么好办法（你说广播吧，广播也是有范围限制的，不可能让世界各地的客户端都收到；最好能跟P2P软件学习，用DHT的方式让客户端和服务器端取得联系，但具体如何实现我还没有头绪；或者客户端内置一些服务器信息，然后可以及时更新，但这样又会让服务器容易被封杀）。也许这就是Tor团队最终弃用Dust的原因吧！

不过Dust的设计思路还是有着可圈可点之处的，而且一直有人维护更新代码，希望哪天能为翻墙事业尽上一份力。

科普文链接集合：https://plus.google.com/109790703964908675921/posts/TpdEExwyrVj

参考资料：
1，https://bridges.torproject.org/bridges?transport=obfs4
2，https://github.com/blanu/Dust
3，GFW的工作原理（1）
                               ————GFW是如何识别并封锁翻墙工具的https://plus.google.com/109790703964908675921/posts/Qs4mjSQEuh7
4，TOR网桥，主动探测攻击和烧钱的GFWhttps://plus.google.com/109790703964908675921/posts/aLcyVfcH7mP
5，https://gist.github.com/clowwindy/5947691
6，GFW的工作原理（5）
                                ——HTTP，老大哥在看着你！
https://plus.google.com/109790703964908675921/posts/K8zYdnEoG9Z
7，https://github.com/blanu/Dust/tree/master/historical/v1