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

guess-wall.txt

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,-229
cn.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,-229
tse3-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,-869
tse4-mm.cn.bing.net:443,+26,-10,+243,-1440,-2777,+182,-75,+485,-2880,-1440,-3301
cn.bing.com:443,+18,-10,+235,-1440,-2777,+182,-75,+3930,-277,+2421,+533
www.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,+1010
www.baidu.com:443,+20,-10,+205,-68,-3584,-347,+126,-226,+668,-1045,+1450,-377,+1019
sp0.baidu.com:443,+20,-10,+205,-68,-3584,-347,+126,+718,-226,-607,+727,-589
news.baidu.com:80,+21,-10,+823,-2902,-1266,-4288,-1192,-2904,-1452,-2904,-2904,-2904,-1452,-4356,-816,+616,-1887
news.baidu.com:80,+21,-10,+601,-3828,+729,-1450,-5554,-2644,-4356,-4356,-2904,-2904,-1452,-1964
avatars3.githubusercontent.com:443,+37,-10,+222,-2856,-1255,+126,-274,+526,-507,+413,-1428,-1360,-124
avatars3.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,-2841
avatars3.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,-2612
collector.githubapp.com:443,+30,-10,+215,-1440,-2111,+126,-51,+1230,-638,+818,-580,+1292,-638,+800,-580,-31
www.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,+46
avatars1.githubusercontent.com:443,+37,-10,+517,-160,+51,+413,-1635,+412,-1428,-1658
avatars1.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,-671
avatars1.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,-1736
assets-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,-441
developer.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,-553
fonts.googleapis.com:443,+27,-10,+212,-2048,-1827,+258,+109,+370,-414,+38,-38,-1518,-46,+46
developer.github.com:443,+27,-10,+517,-160,+51,+524,-2975,+549,-1428,-1360,-2788,-1428,-1428,-2337
ajax.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,+46
developer.github.com:443,+27,-10,+517,-160,+51,+629,-2788,-1428,-1360,-8568,-1428,-1428,-1428,-2651,+574,-978
developer.github.com:443,+27,-10,+517,-160,+51,+601,-2138,+545,-3052,+547,-2788,-17068,-2856,-1428,-4284,-1428,-8568,-1428,-1428,-2466
developer.github.com:443,+27,-10,+517,-160,+51,+574,-929,+546,-7004,-1609,+547,-4216,-1360,-4284,-1428,-1428,-12000
fonts.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 94
live.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

【以上所述都是错的，请各位看官自行判断。】

感謝發文，我還有一個問題
1.隨機填充header真的可以一勞永逸嗎

@leave01 这里提出的方案是对每个数据包进行随机填充，而不仅仅是header。一劳永逸不一定，等待时间的考验。

有人做过统计,"影响"里说尚可以稳定运行的几种代理程序都有被封的情况, 且不是个例

@ccsexyz 如果是每天都有报告被封，那可以认为是已被认证；如果是个例，不排除误伤的可能性。

本周的 週刊アスキー，翻着翻着忽然想起了本文 (´・ω・`)

blinksocks怎么用的，可以搭配魔改后端？