关于墙近期展开封锁的技术分析和规避方案

1. 影响目前已有大量消息证实ss的Stream Cipher和AEAD Cipher相关实现均存在被封锁端口和ip的现象,切换端口或ip后立即恢复,在只改变加密算法的情况下,一段时间后又会被再次封锁。v2ray、ssr以及开启obfs混淆的ss目前尚能稳定运行。 2. 主动探测和被动探测主动探测通过构造特定数据包发往可疑服务端,分析服务端的反馈行为来达到检测目的。显然,构造特定数据的前提是对通信协议已经有了充分的研究,发现了协议本身存在被探测的可能性,才能进一步实施主动探测。对开放源代码的协议进行分析也许不是一件很困难的事,但要对开放源代码的N种协议都分析一遍,再对应实现多个探测逻辑就不是一件一劳永逸的事情了。而在如今各大面板都引入消息认证、自动禁封环节的情况下,主动探测变得比以往更加困难。因此,主动探测是一种高成本、低效率的探测方式,个人认为不会被大面积应用,且近期也从未观察到主动探测情况的发生。 被动探测更关心往返流量的本质属性。前些天广为流传的利用随机森林机器学习算法实现的针对ss流量的分析论文中所述方法也属于被动探测。被动探测相比主动探测,不会在服务端留下任何痕迹,可以在线实时检测,可以做精准流控。被动探测隐密性更好、普适性更强,基于机器学习的被动分析技术也是是未来的发展趋势。 3. 原因分析Q:为什么ss的两种协议会被检出,而v2ray、ssr很稳?A:因为ss没有掩盖其承载的应用程序流量特征的机制。 下面列举一些通过Chrome浏览器直接访问特定网站的流量数据,(+)表示发送(-)表示接收: cn.bing.com:443,+18,-10,+235,-1440,-1440,-1337,+182,-75,+2645,-3333,-2880,-2880,-2485,-3173,-1440,-757,-2880,-2661,-1440,-4138,+2437,-1077,+2437,-901,+2453,-4320,-2880,-821,+2613,-229,+2661,-442,+2421,+3429,-277,+2858,-277,+2549,-3221,-2880,-2880,-1045,-4320,-421,-2880,-853,+2533,-442,+2549,-229cn.bing.com:443,+18,-10,+235,-1440,-1440,-1337,+182,-75,+2469,+389,-293,+2597,-3525,-5760,-2485,-2981,-2181,-2880,-2661,-2880,-2266,+2613,-229,+2613,-2880,-2645,-1861,-2880,-2880,-1605,-2197,-2880,-2661,-2880,-1440,-778,+2613,-229,+2613,-3717,-1440,-2880,-6714,-2197,-2880,-4101,-2880,-1258,+2597,-229tse3-mm.cn.bing.net:443,+26,-10,+243,-2880,-1337,+182,-75,+485,-2880,-1440,-4320,-2789,+485,-2880,-2880,-2880,-2880,-2789,+485,-2880,-2880,-2880,-1440,-4320,-2880,-2394,+485,-2880,-2880,-869tse4-mm.cn.bing.net:443,+26,-10,+243,-1440,-2777,+182,-75,+485,-2880,-1440,-3301cn.bing.com:443,+18,-10,+235,-1440,-2777,+182,-75,+3930,-277,+2421,+533www.baidu.com:443,+20,-10,+205,-68,-1452,-2132,-347,+126,+678,-226,-1452,-2702,-2096,-14860,-4356,-2904,-2904,-1164,+662,-2904,-1125,-4277,+648,-1383,+1010www.baidu.com:443,+20,-10,+205,-68,-3584,-347,+126,-226,+668,-1045,+1450,-377,+1019sp0.baidu.com:443,+20,-10,+205,-68,-3584,-347,+126,+718,-226,-607,+727,-589news.baidu.com:80,+21,-10,+823,-2902,-1266,-4288,-1192,-2904,-1452,-2904,-2904,-2904,-1452,-4356,-816,+616,-1887news.baidu.com:80,+21,-10,+601,-3828,+729,-1450,-5554,-2644,-4356,-4356,-2904,-2904,-1452,-1964avatars3.githubusercontent.com:443,+37,-10,+222,-2856,-1255,+126,-274,+526,-507,+413,-1428,-1360,-124avatars3.githubusercontent.com:443,+37,-10,+222,-1428,-2683,+126,-274,+525,-507,+526,-507,+525,-508,+413,-2788,-3752,+412,-2788,-1428,-508,+419,-2788,-2856,-2856,-2856,-2856,-2856,-2856,-2856,-2856,-2856,-1428,-1428,-1428,-2856,-4284,-1428,-1428,-1428,-2856,-2841avatars3.githubusercontent.com:443,+37,-10,+222,-1428,-1428,-1255,+126,-274,+526,-507,+413,-1428,-968,+412,-1428,-2492,+421,-1428,-1360,-1428,-1428,-1428,-1428,-2612collector.githubapp.com:443,+30,-10,+215,-1440,-2111,+126,-51,+1230,-638,+818,-580,+1292,-638,+800,-580,-31www.google-analytics.com:443,+31,-10,+216,-3978,+258,+151,+288,+302,-418,+38,-38,-443,+46,+72,+364,-231,+46,+72,+301,-185,-46,+46,+72,+346,-231,+46avatars1.githubusercontent.com:443,+37,-10,+517,-160,+51,+413,-1635,+412,-1428,-1658avatars1.githubusercontent.com:443,+37,-10,+517,-160,+51,+413,-2187,+412,-2624,+418,-2788,-4216,-2788,-2856,-2856,-2856,-2856,-2856,-2856,-1428,-2856,-2856,-1428,-1428,-14280,-9996,-1428,-8568,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-7140,-1428,-1428,-1428,-4284,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-2856,-1428,-1428,-2856,-1428,-1428,-1428,-1428,-1428,-2856,-2856,-1428,-1428,-1428,-2856,-1428,-8568,-1428,-1428,-5712,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-4284,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-2856,-1428,-1428,-2856,-2856,-2856,-1428,-2856,-1428,-5712,-1428,-1428,-1428,-1428,-2856,-1428,-9996,-2856,-1428,-1428,-8568,-1428,-1428,-1428,-1428,-1428,-8568,-1428,-1428,-1428,-1428,-671avatars1.githubusercontent.com:443,+37,-10,+517,-160,+51,+413,-2788,-1918,+412,-1428,-2176,+420,-2788,-4284,-1428,-2856,-2856,-2856,-1428,-1428,-1428,-1428,-1736assets-cdn.github.com:443,+28,-10,+517,-160,+51,+561,-2788,-2788,-2856,-2856,-2856,-3976,+561,-2788,-2788,-14280,-35700,-1428,-1428,-1428,-1428,-1428,-1428,-2856,-1428,-2856,-441developer.github.com:443,+27,-10,+212,-1428,-1428,-1255,+126,+582,-258,-1428,-1360,-2576,+540,-7072,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-1428,-2856,-2856,-4284,-2856,-1428,-1428,-1428,-561,+555,-1428,-1360,-1215,+600,-1428,-709,+548,-1428,-1360,-4284,-1428,-1428,-553fonts.googleapis.com:443,+27,-10,+212,-2048,-1827,+258,+109,+370,-414,+38,-38,-1518,-46,+46developer.github.com:443,+27,-10,+517,-160,+51,+524,-2975,+549,-1428,-1360,-2788,-1428,-1428,-2337ajax.googleapis.com:443,+26,-10,+211,-1418,-2457,+258,+109,+358,-413,+38,-374,-2836,-1418,-4254,-1418,-2836,-2836,-1418,-1418,-2836,-1418,-2836,-2836,-2067,+46developer.github.com:443,+27,-10,+517,-160,+51,+629,-2788,-1428,-1360,-8568,-1428,-1428,-1428,-2651,+574,-978developer.github.com:443,+27,-10,+517,-160,+51,+601,-2138,+545,-3052,+547,-2788,-17068,-2856,-1428,-4284,-1428,-8568,-1428,-1428,-2466developer.github.com:443,+27,-10,+517,-160,+51,+574,-929,+546,-7004,-1609,+547,-4216,-1360,-4284,-1428,-1428,-12000fonts.gstatic.com:443,+24,-10,+205,-3488,-882,+93,+53,+98,+390,-375,+38,-1730,-1440,-4320,-2700,-3488,-742,-970,+46 不难发现:访问相同网站会在头几个数据包产生高度一致的数据收发特征,访问不同网站的数据收发特征存在一定差异。 而且,不仅仅是头几个数据包,在一些情况下,应用程序可能还会暴露出更多细节,特别是对于具有心跳机制的应用程序更是如此,比如Telegram、和github的心跳特征: 91.108.56.137:443 u 414 d 385 u 201 d 90 u 94 d 94 110 u 158 d 94 u … d 94 110 u 94 d 110 u 94 94 d 94 u 94 d 94 u 94 d 94live.github.com:443 u 466 d 408 u 319 d 146 u 56 823 d 316 u 78 d 36 u 40 d 36 u 40 d 36 u 40 d 36 u 40 d 36 u 40 42 这就给后续的统计分析或者是机器学习提供了便利。下面再简单分析一下几个代理软件: > ss一向遵从简单、高效、协议特征最小化的设计,对于Stream Cipher: [iv][encrypted data stream… 对于AEAD Cipher: [salt][len][len_tag][data_chunk][chunk_tag][… |← — — — encrypted data stream — — — ->| 很明显的一点是,对于单次数据发送或接收长度小于MTU的数据包,两种协议都无法掩盖应用程序流量特征,第一种最好判断,加密之后的特征和裸跑就几乎一致;第二种也只需要通过简单的修正(本例是减去len和两个定长的tag,当然实际一定会采用更严谨合理的方式),甚至不需要修正,直接进行特征提取、学习、预测就能得出结论。 > ssr的多种协议都具备随机填充,从数据包长度看是无法暴露应用程序流量特征的,因此不能通过上述方法对比得出在访问哪些网站。 > 有意思的是,v2ray的vmess协议在传输应用数据时也无法掩盖特征: [header][len][data_chunk][chunk_tag][… 但为什么vmess能存活,我想原因有两点:一是v2ray提供了多连接复用(Mux.Cool)的功能,复用连接后,应用特征被淹没在流量海洋中,因此能够规避检测,但Mux.Cool协议似乎是明文协议头(没有深入了解)和控制包,容易被发现。二是还没有被针对,vmess协议相比ss要复杂的多,并且header部分也有随机填充,可能还需要一段时间去训练针对vmess的模型。 墙倾向于低成本、高效率、有针对性的(针对协议设计而非实现)封锁方式,对于没有设法掩盖应用程序流量的协议,只需要训练单一模型并不断提升覆盖范围和精度就可以做到批量检测,一劳永逸。 4. 规避检测的方案通过上述分析很容易想出一个除了配置协议混淆插件的简单方法:引入随机填充,当然这个方法也是经过比较和验证成功的。 ===下面是【广告】=== blinksocks可以通过配置预设列表来组合出多种协议: 下面是Stream Cipher的实现配置(当然已经验证会被封锁):{ “presets”: [ {“name”: “ss-base”}, {“name”: “ss-stream-cipher”, “params”: {“method”: “aes-256-ctr”}} ]} 但是,如果对每个数据包进行随机填充,就再也没有发生过封锁现象:{ “presets”: [ {“name”: “ss-base”}, {“name”: “obfs-random-padding”}, // magic! {“name”: “ss-stream-cipher”, “params”: {“method”: “aes-256-ctr”}} ]} 这样简单到甚至不需要进行协议混淆,不需要配置额外的obfs服务,也不需要改443端口配置重定向,轻量、快速、而且有效。 那如果遭遇主动探测呢?上AEAD Cipher。{ “presets”: [ {“name”: “ss-base”}, {“name”: “obfs-random-padding”}, // magic! {“name”: “ss-aead-cipher”, “params”: {“method”: “aes-256-gcm”}} ]} 那如果……还有N种组合方案呢。 如有兴趣,欢迎尝试blinksocks,一个拥有可自由组合协议的代理编写框架。(逃……https://github.com/blinksocks/blinksocks 【以上所述都是错的,请各位看官自行判断。】

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.