从双重标准到“大新闻”：浅谈代理协议设计与实现上的一些本质问题与优先级区别 #19
Description
过年期间比较忙，这文章前天写了一半，今天才写完发出来
有人说代理圈春晚 #16 比 CCTV 春晚更精彩，我不知道，不过这又是反转又是原作者现身指责 Sukka 剽窃洗稿想搞个大新闻又是原东家现身要送他二进宫的剧情也确实挺混乱的（另外 Surge 群和作者觉得被波及了，从去年你说什么 AI 支持只要几个小时什么垃圾协议啥的你群就开始政治正确了，Sukka 黑我的文章就能发、带动群内一阵高潮，但一有人发后续就 被踢出，所以也不好说），目前报道该事件的 Telegram 频道有 在花频道、海豚测速，以及大量引用 Sukka 闹剧原文的 LoopDNS，对于该频道主比较关注的 Caddy 问题，可以参考我早在 2023 年就写的 TODO，正好也借此机会浅谈一下一些本质问题的优先级区别。
从 Shadowsocks 初版到现在有十余年了，代理圈是从来不缺“大新闻”的，至于上篇文章提到的“双重标准”问题，可能是因为对于不懂代理技术细节的吃瓜群众来说似乎并不清楚哪些问题才是致命的、哪些问题会真正被 GFW 利用、哪些问题在专业人士看来优先级较低且升个版本即可解决，要理清这些首先我们要知道代理协议三要素：宏观原理、认证与加解密、反识别，每个环节都存在众多问题但严重程度并不相同，有些问题严重到 XX 协议已死，但有些问题并不需要 breaking change，甚至有些问题在确定被 GFW 利用前并不会获得非常完美的过度修复，因为其它事情的优先级更高，我写这篇文章的目的就在于从技术的角度让广大的代理协议用户、吃瓜群众更好地理解代理协议与我们的做事逻辑，不至于被基于双标的“大新闻”牵着鼻子走。
认证与加解密
也就是通常所说的安全问题，对于精心设计的代理协议来说这方面本不应该出问题，因为一出就是大问题、通常必须改协议来解决。例如按 SS 协议版本历史，最初的几个版本用的是流加密即 XOR，它有能被中间人随意篡改的问题，又因协议结构设计不当被人发现存在“无需密码即可解密”的漏洞（这段历史我不熟悉所以未附上链接），2017 年发布的、同时也是现在中转机场最常用的 SS AEAD 虽然解决了这些问题但又因协议交互设计不当被我发现了 移花接木漏洞，2022 年由非 SS 官方成员设计但沿用了 SS 名称的 SS 2022 虽然解决了该问题但仍因沿用了对称 PSK 的设计而 没有前向安全甚至没有客户端配置安全，拿到客户端密码就能解密以前、以后的所有流量，本来这还需要 GFW 偷到密码但 令人意外的是一些“高端”机场直接共用 SS 密码，也就是说 GFW 可以直接解密它们所有用户的流量，当时我们点出了这个问题，同时也是本次闹剧的导火索。但是上了 TLS 或密钥交换就没有该问题了吗？并非如此，未来的量子计算机可以破解现在记录的基于 X25519 密钥交换的 TLS 流量，所以去年随着 TLS 正式支持 X25519MLKEM768，REALITY 也支持了它并使用 ML-DSA-65 提前强化了认证部分，随后出的 VLESS Encryption 更是整个就面向后量子时代设计。此外常规 TLS 由于依赖 CA 进行认证所以有被 MITM 的风险，更有不少机场直接就是自签证书加完全不验证证书的 allowInsecure，所以既然 GFW 已经在其它国家尝试过大规模 MITM，Xray-core v26.2.6 开始正逐步移除 allowInsecure 选项并建议使用 pinnedPeerCertSha256、verifyPeerCertByName 来替代该选项，它们在未来 Xray 只信任 Xray 内置根证书列表时也会发挥作用。值得一提的是除了代理协议外，基于代理内核的 Web 面板在很长一段时间内都是默认公网明文 HTTP 且 YouTuber 就喜欢这么教小白，也就是说 GFW 可以直接拿到他们的密码、私钥等关键信息，使得任何协议上的安全设计都成为空谈，好在经过各方的持续努力，目前为止 所有 基于 Xray-core 的主流面板 已彻底移除公网明文 HTTP 选项，下一步 Xray-core 自身还会逐步禁止公网未加密出站以防小白配置出错误用法。毫无疑问当代理协议可用时安全问题是最重要的、优先级最高的，所以我们才会不断在这个方向上发力，但可惜它几乎没有得到各个频道的主动关注，不是没 PoC 就等于没问题，可能是需要投稿吧我没投过。
反识别
也就是不被 GFW 识别并封锁，分为“检测/修改流量”和“主动探测”两种，这些问题的严重程度和优先级不一，通常取决于是否需要 breaking change。在全随机数协议还没被 GFW 彻底拉黑的年代，经常有人研究这些问题并搞个大新闻，其中有些问题比如五六年前的 旧 VMess 的主动探测问题 需要更换协议至 VMess AEAD 才能解决，确实配得上大新闻，我也是因为该问题才阴差阳错地开始设计代理、发表了 VLESS BETA 及其理念，SS 的太多了就不提了，其中有些也涉及上文提到的“认证与加解密”。然而不出意外地 GFW 在 2022 年中将全随机数外观彻底拉黑（所以去年出的 VLESS Encryption 默认就不是全随机数外观、也不是为了直接过 GFW），SS、VMess 直连的时代宣告结束，相关研究收敛到 TLS 上的攻防，这也是我早在 VLESS 初版就预测过的最根本的“努力方向问题”，然而 Trojan 虽然使用了 TLS 但从未考虑过 TLS 上的流量特征问题，导致因为 TLS in TLS 问题而被 GFW 一天封一个端口，相信不少人亲身经历过，某些人还说是骗流量、炒作，对此我写了 Trojan-killer 验证了 TLS in TLS 握手问题确实存在，而 Trojan 需要更改协议设计才能解决该问题（虽然也可以利用 TLSv1.3 padding 但广泛实践起来还不如改协议方便）。VLESS 协议从一开始就关注了 TLS 上的流量特征问题并预留了 Flow & Seed 机制以不断适应规避 GFW 最新的检测、封锁策略，确实最初的 XTLS 因为没有过滤掉 TLSv1.2 流量而在 TLSv1.3 中暴露了少量 TLSv1.2 的特征，其实若只要解决这个问题直接更新版本过滤掉 TLSv1.2 流量就行（涉及小 breaking），不过为了同时解决更多潜在的问题，我们选择发布新的、可以结合任意 TLS 库的 Flow 也就是现在大家最常用的 Vision，文中已经说了那些写在代码中的填充长度仍需“拉锯”（并且修改这些填充长度是前后兼容的、并不需要 breaking change），也就是说下一步是等待 GFW 行动，这样 Vision 才能获得更大的优势、延长拉锯时间，Vision Seed 的 PR 两年没合 也从侧面说明了我们的态度：如果过早更新 Seed 然后被 GFW 针对未考虑到甚至可能是更难解决的、其它角度的特征那不就废了，不应把手里的牌一下子打完，但架不住 GFW 还没行动呢有些人就开始拿它们做文章了，所以去年底我们发布了 testseed，正式版 Seed 仍在被其它事项不断插队中，为了更好地理解我们的做事逻辑，你可以看看刚合并的 XHTTP 规避潜在的 CDN 检测的 PR 的前后讨论。
然后说一下“鹦鹉问题”：正如 #16 所述并不是你不想鹦鹉就不鹦鹉了而是基于种种考虑后你可能没得选，像是 SSR 那些一眼假的伪装头确实是不如直接用真的（Xray 最近加的 Finalmask 层也声称了“不具备抗检测的鲁棒性”），但是比如流行的多代理协议内核均选择 Golang 作为开发语言以实现开发新功能、代码维护、多平台分发的便利，但同时也得接受它不容易结合 Chromium/Nginx 的原生网络栈的事实，不是说完全做不到而是开发、维护成本是否值得的问题，在 GFW 已经针对了 Golang TLS 指纹的情况下 uTLS 就是不得已的便利选择，即使众所周知它仅是模拟静态指纹、完全不模拟动态特征，且因缺乏人手维护、审计所以时不时爆出点小问题，但开源社区就讲究一个你行你上，TLS 客户端指纹问题由来已久，早在 v2ray WSS 时代就有人发现 v2ray 默认的 TLS 指纹甚至与 Golang 默认的 TLS 指纹存在差异，懒得找链接了，据说 Trojan 官方库的指纹也有问题只是没人点而已。某些地区的 SNI 白名单未来可能扩散到其它地区，运营商层面对不同的 SNI 也有区别性对待（比如经典 speedtest），在这种情况下你也不得不选择一群伪造 SNI 的鹦鹉，但鹦鹉与鹦鹉之间亦有区别，有些问题本来是可以避免的，比如 Cloak 的 x25519 问题 和 ShadowTLS v3 的 4bytes 问题，这些问题是根本性的设计问题、无法通过简单地修改实现并推新版本来修复，确实称得上“协议已死”，而 REALITY 在设计上尽可能遵循了 TLSv1.3 的语义且它除了双向认证方式外整个就是标准的 TLSv1.3，它的鹦鹉问题都只是实现方式上的小问题、Xray 推个新版本就能解决且不失兼容性，所以在解决了一些最明显、最刺眼的问题后剩下的我直接写了 TODO 不然就是个无底洞，日后若有需要直接改 Chromium/Nginx 也不是不行，甚至用了 AI 只要几个小时，可以看到鹦鹉的问题就是无法完美模仿、特征太多，所以无论是 REALITY 还是 uTLS 都在处理鹦鹉问题上选择了一个合理的适中度，毕竟 GFW 都不一定真的利用它们而是转战其它角度，尤其是当开发者推个新版本就能修复时对 GFW 来说也会觉得对应的检测/探测角度并不长久，比如俄罗斯、伊朗对 REALITY 的回应就是 IP 白名单甚至直接断网，你提前把直连的 SNI 伪造弄得无比完美它有用吗，既然 GFW 都已经 SNI 白名单了人家是否还愿意在这种可被轻易修复的问题上跟你拉锯也是个问题，有时候你是想跟 GFW 拉锯细节问题但 GFW 可能就懒得跟你来回拉锯而是 直接掀桌子，话又说回来了其实你在 TLS 上跑代理并试图隐藏在正经的浏览网页流量中这件事本身就很鹦鹉（比如上文提到的 TLS 上的流量特征问题、TLS in TLS），只是其它类型的流量更不适合大规模承载代理流量。
宏观原理
由此引申出了我要说的最后一件事，即代理的宏观原理，它指的不是如何使流量进入代理软件又如何通过编码 Addr 来传到服务端，而是上文提到的最根本的“努力方向问题”。你是可以不断精进现有原理的协议来使 GFW 更难检测/探测它，但任何拉锯都有一个度，刚刚说过如果超过了 GFW 的预期它就会直接给你掀桌子，就比如很久以前 GFW 还会主动探测你的 SS 但后来 GFW 选择直接拉黑全随机数外观（不过这个确实是太离谱了所以我早就预测过 GFW 会这么干，我甚至早就觉得这个都没得拉锯因为但凡 GFW 是我建设的那么我一开始就会这么干，另外还有致力于抢占带宽的比如 Hy2 也是有点离谱，导致运营商已经大范围 QoS 了），以及刚刚提到的从 SNI 白名单到 IP 白名单，比如你可以看到 REALITY 出现一年后 Xray 发布了 XHTTP，它在伊朗的直连协议失效时发挥过 重要作用，以及鉴于俄罗斯、伊朗的 IP 白名单愈演愈烈所以最近正在开发中的 XDRIVE，它们从根本上就是比处理不完的针对 SNI 白名单协议的鹦鹉问题 更加重要，当然了鉴于 Xray 是一个被世界上所有有反审查需求的地区所广泛使用的代理软件，不同地区适用不同原理的代理协议，所以对于我来说所有 VLESS 相关协议以及 Xray-core 肯定是都会不断完善的，只是如何把自己有限的时间优先用到更重要的事情上的问题。说到这一点，很遗憾的是如今世界上有越来越多的地区开始了不同程度的互联网审查，未来仍需反审查领域的贡献者而不是破坏者共同努力，希望 AI 超过奇点的那一天后世界上逐渐不再需要互联网审查。
最后，祝各位新年快乐。