Total Pageviews

Tuesday 22 September 2015

防火长城的主动探测系统

2010年到2011年,瑞典林雪平大学超级计算机中心的系统管理员Leif Nixon在SSH日志中发现了大量奇怪的登录失败信息,这些刺探性的连接使用了看起来随机的字符串。他最后从IP地址分布中找到了规律:每一次刺探都紧跟在一次源自中国的合法有效登录5到20秒后。他得出结论,这是防火长城干的。他注意到刺探的频率在增加,推测是beta测试结束了,该功能开始广泛部署了。这是有关防火长城主动探测系统的第一份公开报告。
2011年10月4日,一位用户向Tor递交了bug报告,称网桥在中国使用了几分钟后就停止工作。网桥是没有公开的Tor中继,是为了躲避审查系统对公开Tor中继IP地址的封锁。Karlstad大学的研究人员发现,防火长城会在中国Tor用户连上一个网桥的15分钟内尝试与该网桥建立连接,确认是否属于Tor中继,确认之后就将服务器IP屏蔽。
主动探测系统是因应新的翻墙技术而诞生的,新的翻墙技术能抵抗传统的封锁,如将翻墙流量嵌入到TLS流中使得审查系统难以区分翻墙TLS和合法TLS,而域名伪装技术则用看起来无害的域名去隐藏被审查的目标域名,它一般利用的是CDN的域名。
为了避开深度包检测系统的指纹识别,Tor项目在2012年开发了第一个可插传输协议obfs2,它将整个Tor TLS流量封装在一个轻量级混淆层中。但obfs2在设计上有一个重大缺陷,它首先发送一个密钥,然后发送可用密钥解密的密文。审查者可以读取TCP连接首部的前几个字节,将其作为密钥去解密后续字节,如果解密后的字节是有意义的,obfs2也就被识别出来了。2013年3月,Tor用户报告obfs2私有网桥在主动探测后遭到屏蔽。2014年6月,Tor项目宣布淘汰obfs2,转向obfs3,开发obfs4。
obfs3修复了obfs2的设计缺陷,使用Diffie-Hellman密钥交换算法确认通信双方身份再决定用密钥加密后续数据。要识别obfs3连接,审查者要么使用中间人攻击去获知交换的密钥,要么对看似随机的数据进行启发式探测。目前obfs3是Tor匿名网络最流行的传输协议,虽然遭到了主动探测,obfs3的网桥很少遭到屏蔽
SoftEther是另一个受欢迎的分布式VPN服务,它也使用了一个类似Tor的公共VPN中继服务器列表,列表中的IP很容易被防火长城加入到黑名单中。SoftEther开发者采用的一个应对之策是在列表中加入混淆IP,这些IP地址是重要服务的IP,比如根域名服务器和Windows更新服务器使用的IP,所以防火长城不再采用自动方法屏蔽SoftEther,它必须加入一个手动验证环节,这就为蜜罐创造了条件,开发者发现了一个审查者使用的IP: 210.72.128.200,该IP地址被屏蔽之后审查者开始使用云了,如亚马逊的EC2。审查者最新使用的主动探测方法是模仿SoftEther的客户端握手去识别有效的SoftEther的 IP,类似“POST /vpnsvc/connect.cgi HTTP/1.1”,所以现在SoftEther的VPN已很难连上了。
GoAgent曾是另一个受欢迎的翻墙服务,搭建在Google App Engine上,使用Google的未屏蔽IP提供代理服务。我们都知道结果,Google的IP被大规模的屏蔽。审查者使用了主动探测方法去识别可用的Google的IP,它使用了一个特定的主机头文件:Host: webncsproxyXX.appspot.com,xx的值位于1到100之间。它有多个变种,但User-Agent一直保持不变:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/34.0.1847.116 Chrome/34.0.1847.116 Safari/537.36
from https://www.solidot.org/story?sid=45577