关于『VPN混淆』的不完全介绍
『使用VPN混淆，绕过VPN块，快速隐私地无法窥视来自ISP，现在按下按钮，轰！推推，网上冲浪！』
前言
笔者并不是什么VPN高手，但是只是想把自己总结的东西都介绍一下，让更多人对此有点认识。尤其是当笔者看到『用VPN混淆绕过流媒体网站的限制』这样的错误说法的时候....反正是忍不住了
咕噜咕噜搜索VPN混淆的知识，假设你是用中文搜索的，那么能找到的结果大多数有以下两个来源：VPN厂商本身的介绍文，以及各路博主的评测。因此这就存在一个问题：关于VPN混淆的介绍必定是不太全面的，因为，评测推广嘛，肯定是看准了其中一个牌子来介绍的。而VPN混淆其实是一个很宽泛的说法，具体实现和技术细节因人而异，因此很多推广文章都是介绍的是他的结果：
『采用了先进的xx技术，让VPN流量得到混淆，绕过VPN限制』
『让VPN流量混入到日常上网流量中....』
『绕过VPN限制，让上网冲浪更畅快.....』
但是笔者总觉得，应该有那么一个地方，把这些底层知识都汇总一下，好让愿意深究的人能够学习到
于是，就是这里了。
VPN混淆是什么
VPN混淆是『VPN obfuscation』或者说『obfuscated VPN』的直译。
介绍这玩意之前先来点基础知识：
使用VPN上网前，我们的流量是：
你 => 运营商 => 目标服务器一般情况下，使用之后就是：
你（VPN加密） => 运营商1 => VPN服务器（VPN解密） => 运营商2 => 目标服务器当然所谓的什么双跳VPN，无非是多几个VPN服务器转发罢了，原理是相通的
我们平时说VPN流量是有特征的，指的是VPN流量虽然无法知道其中携带的具体信息，但是却可以用DPI的方式来获取到一些特征值，从而判定这个流量就是VPN流量。而且，实际上这个做法并不需要什么太高级的工具，一个WireShark就足够判断了。
其次，你上网的流量必定是要经过ISP的，甚至还可能需要经过GFW。像这样的机构都可以轻松地检测到VPN流量，从而采取限速或者直接掐断等措施。这么做的原因有很多，比如对UDP流量看不顺眼，比如为了反反审查，等等。上面示意图中的『运营商1』就是这样的一个角色，可以有针对性地屏蔽VPN流量
话题回到VPN混淆上。所谓的混淆，主要的作用就是把VPN流量通过额外加密层等方式去除特征，或者更进一步的是，伪装成HTTP/HTTPS等流量，骗过一些比较低级的防火墙，以实现绕过审查的目的
VPN混淆的种类
上面也提到过了，这玩意的实现因人而异，具体技术细节并不一样，有的是采用现成技术，有的是采用自研技术，大致说来，可以分为以下这几类比较常见的：
协议（可能）自带混淆
Lightway
Lightway是ExpressVPN基于wolfSSL实现的一个私有协议，其核心部分在GitHub上开源。官方宣称是『比OpenVPN更快，更轻量，更具有穿透防火墙的能力.....』
....吗？
事实上，笔者对于是否要把Lightway写进来是比较犹豫的。因为Lightway实际上主推的还是使用UDP模式，对于UDP-QoS而言并无益处。此外，其混淆的实现实际上也是不太清楚的。虽然说官方开源了核心实现，但是实际用的是不是这个呢？无从得知。
翻阅官方对于lightway的介绍可见，其中提到了一个『Post-quantum protection』（后量子信息保护）。出现这个东西的原因是，目前的非对称加密技术基本上是基于『大质数分解难』和『椭圆曲线分解难』等技术实现的安全。到目前为止，还没有一个高效的算法能够快速的暴力破解，因此暂时还是安全的。但是科学家推测，在量子计算机出现之后，即使算法不变，也有可能会大大的提高破解速度，原本安全的东西就不安全了。
业内目前对于实现『后量子时代安全』的方式一般是，添加一个对称加密层，通过预共享的密钥（PSK）加密握手过程（甚至通信全过程）。这样，即使真有这么一个方法可以快速破解非对称加密，也还有一个对称加密层可以撑一段时间。
有趣的一点来了：这个对称加密层，如果你仔细思考一下可以发现，实际上变相地起到了混淆的效果。而上一个通过加密实现混淆的代理协议是什么呢？
Shadowsocks！
因此，Lightway的混淆方式可能和这个也是八九不离十的。有用肯定是有用，也不会损坏原本的安全性。但是大量加密UDP流量能不能骗过高级一点的防火墙（比如GFW）呢？只能交给时间去证明了。
Wireguard (with PSK)
和上面的实现差不多，通过PSK的方式去除WireGuard本身的特征。
但是因为笔者对源码的了解并不深入，因此也不敢下定论这个PSK到底作用于哪里，如果有了解的大牛，烦请告知小弟，谢谢。
根据笔者抓包发现：PSK无法达到混淆效果，其并不改变握手特征（比如说：以01 00 00 00开头的握手包）
外置混淆（流量隧道）
有点类似于给现成的协议打补丁，虽然说不是最优雅的实现，但是却是最灵活的实现，出了点什么事，再打个补丁，或者换一个打，就好了
XOR
XOR本来指的是异或算法，其真值表是：
图源互联网采用数学知识不难证明得出，异或运算可以作为加密算法来使用（事实上，现在很多加密算法的核心之一就是xor），粗略来看的话，此时输入的两个值，其中一个可以定义为明文，另一个就可以认为是密钥，输出的内容就是密文。暂且不论这个方法安全性如何（这就是涉及到密码学的深层知识了，此处不过多涉及），但是你应该已经看出来了，这个东西也可以被用作混淆VPN的流量。
于是，就引出了本题目所说的XOR：OpenVPN的XOR补丁，在收发数据之前做一次XOR处理（配置文件中设定好密钥），就可以增加DPI的难度了。
这个方法确实行之有效，简单XOR处理之后确实也无法再被WireShark等抓包软件分析出来。但是问题就出在这：XOR算法本质上还是很简单的，而且最大的问题是，无法抵御频率分析和已知明文攻击。以后者为例，攻击者只需要进行明文 xor 密文的操作，得出的结果就是密钥。明文哪来的？像OpenVPN这种东西肯定有固定协议头什么的，对于有心人而言，分析出密钥到底是多少，也就成了易于反掌的事情。
当然，对于简单一些的防火墙，这种混淆问题不大。但是当咱的对手变成了GFW时，恐怕已经不太适合了
obfsproxy
听说过Tor（洋葱网络）吗？就是那个经常被用来上暗网的东西
obfsproxy正是出自Tor Project之手，属于他们的Pluggable Transports（可插拔传输层...翻译有点怪怪的）的成果之一。具体是怎么混淆流量的，并不清楚（笔者没有仔细读源码），但是其原本的目的是为了让在网络屏蔽较严重的地区的人们可以成功连接上Tor网桥。再后来，人们发现这玩意的适用性实在是太广了（毕竟是Pluggable嘛），因此聪明的人又想出了一个好办法：用它来混淆OpenVPN的流量。
obfsproxy没有进入到OpenVPN的主线中，如果要配合使用，大多数都是用TCP Socket来套娃，也就是obfsproxy先连接到服务器，然后监听一个本地端口，然后让OpenVPN去连接这个本地端口，还不要忘记配置一下路由表，防止流量回环。
麻烦吗？麻烦是麻烦，但是这么做了之后至少能用 —— 放在七八年前，能用这两个字比什么都重要，至少能用了才能谈速度谈质量的不是？
SSH
不知道还有多少朋友用过这个东西：
ssh -N -D 1080 user@host
# -N：不分配shell
# -D <port>：建立动态端口转发，开启一个socks服务器
# 并监听在指定端口SSH的动态端口转发功能，通过在本地建立socks服务器然后用SSH把数据加密后送到远端的方式实现。
其实如果留心观察的话，就单单凭加密这一点，就已经实现了我们的目标之一。在VPN日渐憔悴而Shadowsocks尚未出现之前（大概也就是10-12年）的时候，SSH曾是很多网友『瞬间看地球』的好工具，甚至也是很多朋友第一条学会的cmd/shell命令。在当时，淘宝有SSH账号出售，各个论坛都有SSH账号提供。各种Linux主机，包括提供了ssh权限的虚拟主机，都可以用作代理
既然有动态端口转发，那么也必然有『静态』转发。没错，虽然说人家不叫这名字，但是确实是有这么一个东西：远程端口转发和本地端口转发。用在VPN混淆上，就是用本地端口转发：
ssh -N -L 11940:localhost:1194 USER@HOST这个命令也很好理解，把本地的11940端口映射到远端1194端口，然后本地VPN客户端访问127.0.0.1:11940（TCP），就可以让数据先让SSH加密之后再发给服务器，由服务器SSH解密之后再转给VPN服务器处理
到目前为止，看起来都还正常，毕竟SSH的加密可以去除VPN的特征，看起来是很好了。
不过，按下葫芦起了瓢，前文提到，SSH在老久之前被直接作为加密代理使用的，而且其本身的特征也很明显，因此这种方法和上面的一样，也是适合『限制了VPN，但是没有限制SSH』的场景。对于GFW而言，『22或者其他端口的大流量SSH』就已经有理由让他切断连接了
因此VPN over SSH对于GFW而言，至少在目前，意义不算很大，但是它的核心思想值得借鉴：让流量尽量变得常见
SSL
曾经有人提到过，OpenVPN具有很强的混淆能力，其原因是OpenVPN可以设置为443/TCP工作，这是在互联网上很常见的TLS流量。
怎么说呢，你笑我不懂混淆，我笑你不懂OpenVPN。
我们常说OpenVPN是SSL/TLS-VPN，这没错，但是问题在于OpenVPN用的并不是标准SSL/TLS（至少握手不是），因此可以被DPI轻易检测出来（没错，还是我们的好朋友WireShark）
但是办法总比问题多，有人就要说了，既然OpenVPN的TLS并不标准，我们在外面加一层标准的TLS不就好了嘛，反正一加密就看不出特征来了？
这就是本节要介绍的TLS隧道混淆
目前有一部分VPN公司的『隐形』（Stealth）VPN就是用这种方法实现的，基本技术方案是OpenVPN（TCP）＋ Stunnel。Stunnel是一个提供TLS加密层的软件，可以保护任意TCP连接，而且最主要的是这是货真价实的TLS，要检测出来就很难很难了（除非分析包头熵什么的了）。具体使用方法网上有很多文章介绍，此处不再复述。
当然，也不一定非得Stunnel不可，其他提供类似功能的都可以，比如GOST，比如V2Ray，比如Simple-TLS。
其他对称加密层
此处当然无法完全列举，但是人见人爱的Shadowsocks也包括在内，也有着很不错的效果
关于其的错误说法
人怕出名猪怕壮，一个概念最怕的是什么：被拿来炒作
『VPN混淆可以绕过流媒体网站的限制』
流媒体网站限制VPN的做法很常见，其主要作用是防止你跨区看版权片。但是，这毕竟是一场猫鼠游戏，流媒体网站使劲限制，VPN提供商使劲绕过，已经成了常态。绕过方法很多，包括使劲换IP的，包括买家宽线路的，甚至还有直接和流媒体网站谈判的（据说ExpressVPN就是如此）。
但是不管怎么样都好，VPN混淆和流媒体网站限制没有半毛钱关系
根据上面的流程图可知，VPN混淆仅作用于『你』到
『VPN服务器』这个范围内。而流媒体网站只能检测到『VPN服务器』到『他的服务器』这个范围，牛头不对马嘴，怎么可能有关系呢？
『VPN混淆可以让你在限制严重的国家连上』
这个说法半对半错
对的方面是，混淆确实可以降低被检测到的概率，这个无可厚非（之所以不是无可非议，是因为这个谁都说不准，除非你就是防火墙的开发者）
但是另一方面，这个问题我在上次的博文里讨论过，简而言之就是，一切的混淆，前提都是你可以连上这个服务器，如果是IP封禁等方式让你连都连不上，那么混淆再高级又有什么用呢？
『VPN混淆可以让你提高网速』
这说法也是半对半错的，主要取决于你怎么理解『提速』。
首先请记住，任何混淆和隧道技术都会减速，比如原来有100Mbps，加上VPN可能只有80，再加个混淆可能只有60Mbps了。
但是其次是，假如你的ISP上了QoS，或者你的对手是GFW，反正就是对于非常见流量限速的，那么混淆成常见流量确实可以绕过这个限制。还是上面100Mbps的例子，假如运营商把VPN流量限速到1Mbps，那么加上混淆之后运营商无法主动限速，当然也就不会轻易限速为1Mbps。但是你的速度也绝不会超过100Mbps，毕竟实际上限就在这
写在最后
猫鼠游戏是没有尽头的，我们能做的就是尽量拖久一点
或者，掰块奶酪吃吃？
深山踏红叶，耳畔闻鹿鸣，感谢您的阅读
（全文完）
对于 obfs4，博主说：
> 具体是怎么混淆流量的，并不清楚（笔者没有仔细读源码），
对于 WireGuard，博主说：
> 和上面的实现差不多，通过PSK的方式去除WireGuard本身的特征。但是因为笔者对源码的了解并不深入，因此也不敢下定论这个PSK到底作用于哪里 [...] 根据笔者抓包发现：PSK无法达到混淆效果，其并不改变握手特征（比如说：以01 00 00 00开头的握手包）
博主可能现在已经意识到了，但还是想提醒一下博主：了解某个程序的工作原理，阅读代码与抓包都不是必须的，大多数时候阅读技术文档即可。当然，对于鱼龙混杂、谣言满天飞的代理工具圈子，亲自阅读代码、抓包的批评精神的确是十分有必要的。不过，对于 obfs4 以及 WireGuard 这样高度学术性的项目，其文献是高度可信的，建议节省自己宝贵的时间，就不必读代码了。
例如对于 WireGuard 而言，如果你想知道 PSK 的作用，只需阅读 https://www.wireguard.com/protocol/ 的文档即可看出：
> If an additional layer of symmetric-key crypto is required (for, say, post-quantum resistance), WireGuard also supports an optional pre-shared key that is mixed into the public key cryptography. When pre-shared key mode is not in use, the pre-shared key value used below is assumed to be an all-zero string of 32 bytes.
从这个介绍中我们就可以看到：
1. 引入 PSK 的原因并非“混淆“流量，而是用对称加密作为后量子时代到来，X25519 公钥加密被攻破后的”兜底“措施。
2. PSK 是被“混合进”公钥密码算法的。
3. 当未开启此模式时，PSK 为 32 个 0x00。
那么 PSK 是如何被“混合进”公钥密码算法的，只需要搜索关键词“preshared_shared”就能找到这个密钥唯一的出现在“Second Message: Responder to Initiator”：
temp = HMAC(responder.chaining_key, DH(responder.ephemeral_private, initiator.static_public))
responder.chaining_key = HMAC(temp, 0x1)
temp = HMAC(responder.chaining_key, preshared_key)
responder.chaining_key = HMAC(temp, 0x1)
可以看到，preshared_key 唯一的作用是完成 DH() 密钥交换得到对称密钥后，作为额外的一次运算，对 DH() 的原始输出结果用 HMAC 函数再“搅拌”一次，使加密安全性不再依赖 DH() 函数的安全性，仅此而已。开启 PSK 唯一的效果，是改变 X25519 非对称加密交换密钥后得到 ChaCha20 对称密钥结果，而不会对 WireGuard 协议本身的运作有任何影响。
再例如 obfs4 的混淆，也同样可以阅读 obfs2 [1][2], obfs3 [3][4], obfs4 [5] 的协议文档了解基本设计原则。我们还可以在 arXiv 上找到一篇非常好的综述，同时这也是 obfs4 前身算法 ScrambleSuit 的描述 [6]：
我们可以看到：
1. obfs2 的本质就是非常简单的 AES-CTR 加密。
INIT_SECRET = MAC("Initiator obfuscated data", INIT_SEED|RESP_SEED)
RESP_SECRET = MAC("Responder obfuscated data", INIT_SEED|RESP_SEED)
甚至默认连预共享密钥都没有，仅是用两个硬编码的字符串，再加上两边发送的随机种子衍生一个密钥。任何监听连接的人都能破解。如果开启了可选的 PSK，那就用 PSK 修改 MAC 的输出（和 WireGuard 的对称加密兜底机制思想一致）：
MAC(s,x) = H^n(s | x | H(SECRET) | s)
obfs2 唯一的功能的就是隐藏 Tor 本身的 TLS 握手信息，没有其他功能。而且主要功能只是 Tor 的 Pluggable Transport 框架的技术演示。它没有密钥交换功能，也没有信息完整性校验功能，也不防主动被动探测。显然这种玩具很快就被攻破了。
2. obfs3 在 obfs2 的基础上进行了升级，主要是加强了握手过程，加入了真正的 DH 公钥密钥交换。但众所周知，DH 密钥交换特征过于明显，于是 obfs3 基于标准的 DH-1536 稍加魔改，开发了一个名为 UniformDH 的公钥加密算法，实现了“看上去完全随机”的 DH 握手报文，防止 DPI 检测符合 DH 格式的报文。但同样，这个协议也没有防主动探测的功能，任何人都可以与 obfs3 服务器进行 UniformDH 握手。
4. obfs4 则是进行了全面升级。首先是将 DH-1536 升级成了 Curve25519 提升性能，并同样进行魔改，开发出了类似 UniformDH 的 Elligator 2 密钥表示法，让 Curve25519 公钥与随机报文不可区分。同时，每台服务器还有“身份密钥”和 Node ID，没有则无法进行握手，以防止主动探测。此外，还采用了 ScrambleSuit 的”多态化“想法，对报文长度按照一个随机概率分布进行了随机化（禁用 Nagle 算法，防止内核重新打包报文），时序也进行了 1-100 毫秒的随机化（可选，不知 obfs4 默认是否开启了）。
我们可以看到，obfs4 与中国大陆的代理工具开发思路明显不同。一个是学院派建筑师，做出来的东西在技术上需要是严谨的，甚至要新颖有趣；而另一个是野路子装修游击队，只要能实现目的，国标、安规都不要紧。
obfs2 最不严谨，但 obfs3/obfs4 的侧重点都是：如何修改一个公钥加密算法，使其不可检测？无论是 UniformDH 还是 Elligator 2，都在玩密码学智力游戏——这东西是可要发论文的。而 obfs4 则是其中最严谨的，其握手已经采用了 NaCl, SipHash, Curve25519 这些当时非常先进的工具。而 Shadowsocks 等中国大陆的代理工具，侧重点则是：如何让流量不可检测，哪怕扔掉公钥加密？其侧重点是“简单粗暴”、“能用”，保密性并不重要，反而接近原始 obfs2 的思路，所以也没人在意硬编码 AES 密钥会不会有泄密风险，或者 Shadowsocks 协议本身是否有漏洞。
历史上 Shadowsocks 多个漏洞引发的相关争议正体现了这一区别。学院派认为突破封锁的本质是智力竞赛，要设计一个巧妙的协议，并批评游击队丝毫不重视强加密的基本设计原则，而游击队的辩护者则认为这一对抗的本质是土制工具的游击战，只需要土制工具的出现速度大于当局的封锁速度，并不需要土制工具严谨、可靠。
如果有机会重新再来，我觉得 Tor 的 Pluggable Transport 模式可以调和两者的矛盾，两个目标并不冲突。用一个协议严谨的标准加密工具（如 stunnel TLS）做后端兜底，用 Shadowsocks 等土制工具当前端传输层。但显然大多数人只希望简单能用就行，并不希望再引入一个功能只有强加密，实现密码学公认的安全协议，引入复杂度并降低性能的前端。更何况如今 Web 都强制 HTTPS 了，这一问题也自然过时了。
[1] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfsproxy/-/blob/HEAD/doc/obfs2/obfs2-protocol-spec.txt
[2] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfsproxy/-/blob/HEAD/doc/obfs2/obfs2-threat-model.txt
[3] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfsproxy/-/blob/HEAD/doc/obfs3/obfs3-protocol-spec.txt
[4] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfsproxy/-/blob/master/doc/obfs3/obfs3-threat-model.txt
[5] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/blob/HEAD/doc/obfs4-spec.txt
[6] https://arxiv.org/abs/1305.3199
非常感谢您的评论！这篇博文其实写于较长时间之前了，后续也做了一些研究，但没有更新过来
1. 关于wg的psk，当时写这玩意的时候，并没有阅读（甚至不知道为什么遗漏了）protocol页面，其实要是认真读的话，只需要知道在不添加密钥的时候，默认为32位全零就够了（对hmac来说相当于有一个固定的硬编码值而已，不管设置不设置这个psk都是要用某个值去搅拌一圈的）
2. Obfs系列PT，或许可以解释我之前的一个疑问，也就是国外大厂VPN他们的混淆手段，为什么是相对『常规的』给你上VPN over SSH，或者over Stunnel，本质上他们是想要用强加密去对抗硬破解（如obfs2），顺便消除流量特征。这两种算法，本质上是有标准，或者说长时间检验的，总比一个野路子的声称有效的算法要好的多，至少能满足他们作为商业厂家的合规性要求（他们的基本盘还是国外其他用户的，他们对合规/隐私/声誉的要求非常高）。不过很可惜的是，这两种方式在今天来看都不合适了，前者是因为SSH本来就被用过于此用途所以格外引人注目，后者的话更像是会碰到之前提的TCP meltdown问题，实际体验恐怕不是一个差字了得。
3. 关于最后一点，我个人的拙见是要明确区分安全边界，最好能清楚目前正在用的工具能做到什么不能做到什么，而不是假装他能做到什么。比如我用ss，我就得明白，他一旦出现配置文件泄露的情况，就能解密所有通讯流量，安全度不及正经的（带密钥交换的）其他协议。我估计学院派的担心就来自于这里，一个实现不严谨的混淆协议（最极端的例子如多字节XOR），容易模糊安全边界，让人以为他能做到高强度的加密效果，但实际上不能，结果轻则被破解或检测到，重则（结合tor的目标用户群来看）使用者被强力部门因此而查获。
感谢您提供的参考文献，有空我会阅读的
> 比如我用ss，我就得明白，他一旦出现配置文件泄露的情况，就能解密所有通讯流量，安全度不及正经的（带密钥交换的）其他协议。
博主可能关注代理工具较晚，没有经历过 2015-2020 年那段时间关于 Shadowsocks 血雨腥风、人身攻击、真假漏洞、论战炎上的那段时间。
Shadowsocks 历史上的安全问题，远不仅是“固定了密钥，没有前向安全”这么简单，而是存在“理论上攻击者可以伪造甚至解密报文”的严重漏洞。Shadowsocks 历史上的基本实现，仅仅是一个入门教科书级别的无认证纯加密，单纯把所有报文过一遍加密算法；而并没有遵循最佳实践，实现 HMAC, AEAD 等其他校验措施。这就导致服务端会盲目回应无效密文以及篡改后的密文，为一大类 ciphertext malleability 的攻击（以及衍生出的各种重放攻击）敞开了大门。
G-W Rep-rt 有一篇综述，见 [1]。我自己再综述一遍。
2015 年，br-akwa11 是最早认识这一问题的开发者之一，提出可以利用 ciphertext malleability 枚举大量密文，最终找到一个不会被服务端立刻关闭连接的有效密文，用作主动探测。但遗憾的是，由于 breakwa11 本人有限的技术，往往提出问题却无法提供足够有力 PoC；再结合他作为 SS 衍生工具 SSR 开发者所做出的大量其他的争议行为，总体上被当作一个 SSR 广告销售员（导致其最终退网删号，不过这与技术无关，就不讨论了）——对于这个有价值的技术问题，没有人研究技术，只有人身攻击。不过后来在 pr-nsss 与 mad-ye 等有识之士的合作下，在 2017 年，shadowsocks-libev 总算加入了 AEAD 算法。但大家对“无 AEAD 就不安全”的说法依旧半信半疑，非 AEAD 算法依然普遍使用。
结果到了 2019 年，终于有高手 edwar-zpeng 发现这问题比，更是发现问题比人们想象的更加严重，理论上攻击者可以利用 ciphertext malleability 发动中间人攻击，从而解密数据。
后来社区又掀起了一轮代理工具攻击研究热潮，发现了千奇百怪的各种漏洞（例如 V2Ray 的重放漏洞）。
> 我估计学院派的担心就来自于这里，一个实现不严谨的混淆协议（最极端的例子如多字节XOR），容易模糊安全边界，让人以为他能做到高强度的加密效果，但实际上不能，结果轻则被破解或检测到，重则（结合tor的目标用户群来看）使用者被强力部门因此而查获。
按照学院派的看法，密码学协议充满陷阱。即使算法本身都是安全的，只要使用的顺序或者方式不对，或者缺失了某个考虑，依然会存在漏洞。唯一安全的做法是使用如 NaCl 等现有协议或者框架，如果要自定义协议，至少按照符合公认工程规范的组合方式。否则，其他原创的任何协议都是高度可疑的。
Shadowsocks 充满安全漏洞的历史，正是违反学院派原则的后果。任何符合工程或者学术规范的正规加密工具，是不允许出现这些漏洞的。原本的 Shadowsocks 协议，按照学院派标准，那就是一个不合格的毕业设计————考虑到 Shadowsocks 的前身仅是一个几百行的个人自用 Python 脚本，缺乏严谨设计是不足为奇的。但后来大规模将其推广为代理工具，在学院派看来是对用户严重不负责的行为。
相比于不鼓励胡乱创新的学院派，实践派也并非没有大人物支持。其中一位代表人物正是《G-W 技术评论》的作者。后者的观点是“后勤论”，代理工具的本质是游击战，其目标是可访问，而不是打造符合密码学学术规范的安全工具。所以应该鼓励（即使安全性可疑的）发明创造，因为只要需要民间工具的出现速度大于被封锁速度，那就是胜利。如果追求密码学安全，反而会拖慢“后勤”，造成效率严重下降。
当时面对这场论战，我个人的观点，代理工具界应该引入 Pluggable Transport 的模式。首先开发一套严谨可信的的加密协议内核，而将类似 Shadowsocks 这样的代理工具仅仅作为传输，不提供任何安全功能。但显然，对于这样一件只能改善理论安全性，对实用性贡献为负的工作，当时显然没有人愿意去的。
不过现在时局已经大幅变化了：
1. Shadowsocks 这类教科书级的安全漏洞已经修复了.
2. Web 普及了 HTTPS，几乎 99% 的情况可以兜底。
3. 目前的 Xray, REALITY 等开发者的共识是，Shadowsocks 类自创协议本身前景极其有限，会陷入攻防泥潭。基于 Web 与 TLS 的方案才是正道。
因此以上的争论就成为了从未完全解决，但已经完全过时的讨论。
[1] https://g-w.rep-rt/blog/ss_advise/en/
* 部分内容有修改，避免直接的关键词识别
1. 那段时间的血雨腥风，事后其实有所耳闻，但确实不是亲历者（大概是19年才开始上手研究学习加密代理，之前都只是用各种『一键』工具），当时的想法大概是站在用户的角度看的，即『只要能用，我就会用』，并没有过多关注这后面的各类事情。
2. SS密文枚举，以及后面提到的利用合法服务器来解密报文，这个看过相关的介绍，从密码学的角度来看，确实是完全不合格的。实践派和学院派的分歧，感觉还是落在了代理工具的『意义』上，即，开发重点到底是重在『防破解』还是重在『防识别』，但很多情况下，正如你之前所说，其实两者在部分意义上还是有些共通的
3. 基于TLS修改确实是大趋势，但我比较担心的一点是，如果又出现魔改不彻底的情况，会不会类似Tor的TLS那样，也被抓特征，所以感觉还是谨慎为妙
系统设置了3层的回复限制，如果您还有更多的回复，也可以选择发信到邮箱（见联系方式，最近在准备GPG），谢谢
国外厂商在国内体验不尽如人意的几个原因，
协议多半是openvpn/wireguard这些并非为国内设计的协议，旁路流量检测这一关都过不了，更不用说主动探测。
据观察，大部分服务器都是那几家，datapacket m247等，VPN不限制流量的营销策略导致大部分服务器都是那种国际线路的unmetered机，对国内优化并不好。接了亚太pccw的机在某些运营商环境可以直连，尤其是ipv6。
如果真的重视国内市场，最外层套reality协议，内层用wireguard/open vpn这样的全加密安全协议，实际效果会比直连全加密协议好很多。
1. 又想起个有趣的事情，早期WireGuard刚出来的时候秒天秒地秒空气，大家觉得是新希望，最后抓包一看，笑死，特征比ss还明显
2. 这个确实是，基本上就是几个大机房来来去去的，也能观察到去香港180ms+的情况。而且老实说，他们做全球市场的，国内市场只是一部分，很难为了一部分市场去经常上心维护，换IP什么的
3. 除了不重视之外，可能还有部分是重视错了方向（绝大部分都是如此，重点依然放在强加密上，或者使用OpenVPN over SSH等，甚至对着一个已经被阻断的IP堆强加密，意图绕过），或者假装重视