2012年11月28日星期三

(In 2012-11-28)关于eD2k服务遭审查

21:10:08: 正连接到 eDonkeyServer No2 (212.63.206.35:4242 - 支持迷惑协议) ...
21:10:09: 连接到eDonkeyServer No2(212.63.206.35:4242),发送登陆请求
21:10:09: eDonkeyServer No2 (212.63.206.35:4242)可能到达最大客户连接数了

大家有没发现上面的数据非常奇怪?既然服务器“可能到达最大客户连接数了”那服务器应该是负载很重的状态,而且实际延迟360ms左右,几乎就是瞬间报告说连不上?有种这个信息不是真正服务器发来的感觉,于是进行了抓包:

(很不幸地由于 Google 账号的问题,图片已经无法显示了)

如图,留意红色的三行,SEQ1+1490=SEQ2+2920=SEQ3
显然,GFW已经实际对国内所有客户端连接境外eD2k服务器的迷惑协议部分进行干扰,也就是说实际上国内的客户端已经无法使用迷惑协议连上境外的大部分eD2k服务器。

关于eMule模糊协定的资料:

迷惑协议的效果是使传输的数据包“缺乏固定的特征,没有办法被简单的识别出来”,也就是说,GFW对大家使用eMule下载和共享的文件非常感兴趣,但这个迷惑协议提高了审查的难度,于是GFW干脆将其阻断,迫使eMule程序使用普通连接(eMule预设的方法是当迷惑协议连接失败时会使用普通连接再连接一次,而很多eMule客户端包括官方客户端默认也没有启用迷惑协议)传输共享文件信息到服务器上,彻底审查大家共享的文件
据预测,审查位于国际出口上所有TCP协议端口的数据极其浪费审查设备的性能,事实上也没有这个必要,所以GFW应该是将所有能发现的位于境外的eD2k服务器的端口定点清除,因为通常这些端口都是公开广泛传播并且是长期固定的。

在干掉迷惑协议后,GFW便可以轻松对eD2k协议进行审查:

(很不幸地由于 Google 账号的问题,图片已经无法显示了)

1.图中①客户端向服务器端1887端口发送搜索文件的请求,图中③所示是传送的内容:e3:0a:00:00:00:16:01:06:00:e6:b5:8b:e8:af:95 ,其中 e6:b5:8b:e8:af:95 是“测试”的UTF-8的十六进制编码,显然在这里“测试”是敏感词之一。

2.留意图中②所示,20ms后马上收到3个TCP协议的RST包:SEQ1+1460=SEQ2+2920=SEQ3 ,确认是GFW发送的伪造数据包,而这3个数据包是从“服务器端的1887端口”发送过来的, 可以确定是GFW针对上述文件搜索查询而进行的连接重置。

也就是说,eMule客户端使用迷惑协议连接至境外服务器时会立即被GFW重置连接,迫使客户端使用普通连接重新连接境外服务器;而此时若客户端向境外服务器发送文件搜索查询,GFW会审查搜索的关键词,若发现存在敏感词则马上将连接重置,从而使客户端无法得到搜索结果。

以下是部分对应时间轴的日志:
01:15: 正连接到 UsenetNL.biz No1 (91.225.136.126:1887 - 支持迷惑协议) ...
01:16: 连接到 UsenetNL.biz No1 ,发送登陆请求
01:16: UsenetNL.biz No1 可能到达最大客户连接数了(被GFW连接重置迷惑协议握手)
01:16: 正在连接到 UsenetNL.biz No1 ...
01:16: 连接到 UsenetNL.biz No1 ,发送登陆请求
01:18: 连接建立于: UsenetNL.biz No1(客户端与服务器建立普通连接)
01:18: received an IP: ……, NAFC-Adapter will be checked
01:18: 新的客户ID为 ……
01:24: 失去与 UsenetNL.biz No1 的连接(搜索敏感词,GFW重置客户端与服务器之间的连接)

说白了,GFW做了这么多工作,就是想让使用eD2k网络的客户端例如eMule等无法从服务器获取部分敏感文件的来源,或者不允许任何试图通过eD2k网络共享的敏感文件散播。

而针对无服务器的Kad网络方面,现阶段收集到的反馈,由于Kad网络的迷惑协议还未实作,所以技术上审查起来还是比较容易的,但由于属于纯P2P网络系统,实际操作可能会占用大量审查设备的资源,估计也还未进行这方面的实践。
不过不能排除有关部门还会使用另外的方法干扰Kad网络的运作,例如伪造各种虚假Kad节点收集信息(参见Tor在国内被干扰的事情)或者干脆布置大量假的节点,也就是说可以频繁变换自己的身份然后利用假档和发送损坏数据的方式干扰eMule的传输(虽然eMule拥有ICH和AICH功能防止文件传输出错,但事实上如果整个网络都找不到真正可信的文件信息,它们的工作也是徒劳的),或者直接就不散布文件信息阻塞共享文件信息的传播,达到控制广泛散布的目的。

2012年11月20日星期二

(In 2012-11-20)关于近日IPv6隧道被阻断连接

近日看到一篇文章声称防火长城已经具备审查IPv6协议的能力

文章还附上了WireShark的抓包结果:



可见上图,访问了一个大概含有关键词的域名,然后马上被发了RST包RESET了连接,非常典型的HTTP协议URL关键词连接重置;而下图则是查询DNS服务器 twitter.com 的结果,却被防火长城抢先返回了虚假的结果 1.1.1.1 和 255.255.255.255 随后正确的结果抵达,也是很典型的域名服务器缓存投毒污染。

  这确实让人感觉悲哀……但看清楚,发送的 Destination 和接收的 Source 虽然确实是Google的IPv6服务器地址,但是发送的 Source 和接收的 Destination 却是2001开头的IPv6地址,也就是IPv4转换地址,可见博主是使用的IPv4的隧道访问位于境外的IPv6隧道服务器,再由位于境外的IPv6隧道服务器访问Google的IPv6服务器。因为隧道对于用户来说是透明的,所以这里除了转换地址基本看不到位于境外的IPv6隧道服务器的痕迹。

  通过IPv6隧道,位于境内的博主与位于境外的IPv6隧道服务器基于IPv4协议进行通讯,也就是将IPv6的报文封装在IPv4协议的数据包里。而因为分片的问题,同时IPSec对于IPv6现在已经不是必须项目,而且也需要双方同时支持IPSec才能实现,所以在没有IPSec的保护下,位于境内的博主与位于境外的IPv6隧道服务器之间的通讯被一览无遗,只要稍加研究IPv6隧道通讯包的结构,结合IPv4时代积累的丰富会话劫持的经验,实现对IPv6隧道的审查对防火长城来说,完全不是一件难事。

  所以,这其实也不是很让人惊讶的事情。

(In 2012-11-20)Google+的封锁方式研究

  作为比较早加入Google+的人士,一直有研究防火长城对Google+的封锁方式,这也是对自己网络技术一个很好的锻炼机会 =w=
  众所周知的是,Google+因为其极高的曝光率、运营公司的敏感性和用户能自主产生不受审查的原因,发布仅仅3天即遭防火长城屏蔽而在中国大陆无法正常访问至今。
  本文章着重研究的是对Google+的封锁方式。

  • Google+刚刚发布,也就是正在内测的时候,防火长城就已经率先下手:
错误101 (net::ERR_CONNECTION_RESET): 连接已重置
这是Chrome浏览器返回的错误信息,很明显,因为Google+强制使用TLS/SSL加密连接,就算用户使用普通连接也会被跳转到加密连接,这样做变相等于封死了Google+的访问。
  对于技术,也就是服务器的IP地址同时在443端口上进行TCP传输层面的连接重置,也就是刚开始的状况。


  • Google+正式开放注册的2011年9月21日时,封锁方式又发生了变化,当时访问Google+会获得如下错误信息:
错误 118 (net::ERR_CONNECTION_TIMED_OUT):操作超时。
显然,此时无法正常访问的原因是数据包无法到达目标服务器,而与此同时访问普通连接却能正常跳转到加密连接,如此可看出这时服务器的443端口被丢包封锁了,也就是TLS/SSL加密连接必须使用的端口,这也变相等于阻断了加密连接。


说了这么多都是以前的信息,我也知道现在绝大多数人的观点也只停留在上面服务器443端口被封的阶段。但事实上,情况早已有所变化:

现在访问Google+获得的错误消息也还是:
错误 118 (net::ERR_CONNECTION_TIMED_OUT):操作超时。

但事实却没这么简单。大家可以看一下这幅图:

你可能会说:这幅图能说明什么?
这幅截图能告诉我们的信息实在是太多了!

Windows下的命令是 nslookup flweihjgoiwplus.google.com 8.8.8.8
作用是向 8.8.8.8 这个地址发送DNS查询域名 flweihjgoiwplus.google.com

  问题就出在这里:flweihjgoiwplus.google.com 根本就是不存在的子域名(Google也从来没有做过泛域名),怎么会有解析结果呢?这里大家可以参考维基百科上域名服务器缓存污染的条目:
在中国大陆,对于所有经过防火长城的在UDP的53端口上的域名查询进行IDS入侵检测,一经发现与黑名单关键词相匹配的域名查询请求,其会马上伪装成目标域名的解析服务器给查询者返回虚假结果。由于通常的域名查询没有任何认证机制,而且域名查询通常基于的UDP协议是无连接不可靠的协议,查询者只能接受最先到达的格式正确结果,并丢弃之后的结果。
  显然,这就是防火长城发过来的虚假解析包。于为什么发过来的虚假解析包里的IP地址属于Google?这个大家可以向有关部门咨询。
  而现在我知道的是,这两个IP地址的443端口被封了,所以事实上请求解析被投毒污染到这些IP地址上,等于无法正常访问,而因为IP地址是Google的,所以不明就里相信表面现象而得出的结果,大概也是人之常情了。