连续剧 又更新了，半个月前 Surge 发了个“关于 VLESS 协议的说明”，我说“正在开始写一篇文章简评一下”，鸽了半个月终于写了
当时正值“中转/专线”开始被全面清退，这也是我早就 预言 过的，毕竟治不了国外还治不了国内吗，不过当它真的来的时候也还是有唇亡齿寒之感吧，然而由于 Surge 生态长期对直连主流 VLESS 生态 嗤之以鼻 且 更加推崇 “中转/专线”生态，于是被 反噬 了，Surge 论坛出现了大量要求支持 VLESS 的贴子但被删除，恰逢作者忙于装修而疏于更新，推特上评价工人的推文被众人套模板 反评 作者，推特也改为了“仅允许经确认的关注者查看”，于是 Surge 发了两篇声明，一是上面那个说明，二是订阅期自动延期策略以安抚群怨，叠上上个月的 Mac 端 bug 差点需续费才能修复事件导致的群怨，这是事件背景，海豚测速、在花频道、小声逼逼 等频道亦有报道
这样的结果有必然也有偶然：当一群人习惯于躺在围绕着喝茶营销高价、但实际上价不配位的假 omakase 构筑的“谜之优越感”舒适区，没有什么真东西却出于“迷之优越感”而经常看不上包括但不限于专注于反审查、不断积极更新的另一群人，狼没来时随便蹦跶互喷，掩耳盗铃自欺欺人，但当狼真的来时必然会最先翻车，这种事大清已经经历过了；偶然的是 Surge 最近的口碑确实挺差的，即使没有 VLESS 事件，其它一些操作也挺迷的，群人数确实也越来越少了，上面那三个频道发过很多我就不多说了；另一个原因是 Sukka 去年在 Surge 群表示 VLESS 要完了、“除夕夜来波大的”，更加坚定了 Surge 不支持 VLESS 的信心，比如有人问为什么不支持 VLESS 时某管理员称“到时候就知道了”、“时间站在我们这边”，结果现在“中转/专线”先凉得更彻底，虽然也波及到了直连但直连还是更具韧性
聊完人性的东西该聊技术了，我只是想评论一下就比如说
此外，XTLS 将 TLS 从传统的端到端数据保护层重新定位为一种会话引导机制，把原本由标准协议层提供的完整性保障，部分转移到应用自行定义的数据路径之上。这种跨层设计虽然带来了某些特性，但降低了安全边界的可验证性。
我们知道 XTLS 功能之一是允许内层 TLSv1.3 流量“裸奔”，它带来的特性一是很明显的性能最强，且可以通过 ReadV、Splice 等技术进一步增强；二是后续流量完全就没有“TLS in TLS”，比如代理浏览器时后续流量特征完全符合浏览器的特征，尤其是会有 h2 小包等，且不会出现其它代理协议中非常明显的“h2 小包双重加密”，也能避免异常的“显著包长度增长”、“持续超过 MTU 限制”（引用 Naive 的说法）等，这些是它独一无二的价值所在。
当然也会存在一些问题但“降低了安全边界的可验证性”？这么说吧，ECH 都知道吧，XTLS 几乎就是 ECH，同样是只加密了 inner TLS 的握手部分，而后续 TLSv1.3 已经是 AES 加密过的，除非 AES 被破解了否则没人能破解出内容，它和 ECH 解决的是同一个问题，当然 ECH 解决不了的问题它也解决不了；标题中还提到了 EIP，即 Encrypted IP，很简单，这是因为实际上你就是在用你服务器的 IP 来“加密”真正的目标 IP，这下被你提前用上了。提一嘴下个月计划 #26 (comment)
既然 XTLS 是把 inner TLS 拼接到自身，那么有没有一种可能我们还能先和一个白名单网站握手，随后把自身的 TLS 流量拼接上去？这是和 XTLS 孪生的想法，这句话我本来要写到 REALITY 文章里的但不小心鸽了，我说我早就想出 ShadowTLS 这种东西了吧，即使有很多证据但还是有人“调侃”，现在这么一想是不是就很丝滑了？显然你还要有额外的东西来加密自身前面的 TLS 握手，但当时我并没有自己写个“土制加密”的打算就先鸽了，加上消失了一段时间，回来的时候已经有人写了 ShadowTLS，那我更喜欢另辟蹊径，比如说有没有一种可能我不写“土制加密”了，我直接复用 TLS 的整个握手和加密，我研究了一下可行，于是就有了 REALITY，它也是第一个这样做的协议，并且最大程度遵循了 TLSv1.3 的语义以方便升级，比如升级了抗量子。
最离谱的地方是什么呢，同样是“跨层设计”、且 Surge 已经支持的 ShadowTLS 才是真正降低了你数据的安全性，因为它传输数据靠的并不是 TLS 而是 连前向安全、客户端配置安全都没有的 SS，你可以说 inner 流量大多是 TLS 但那也不全是啊，就算是 TLS 也至少能解出你的 SNI 吧？而 XTLS 是用 TLS 把 inner SNI 加密了、且确认流量是 TLSv1.3 才会“裸奔”。这不是很明显的双标吗？ 何况 ShadowTLS v3 由于设计不当 已被精准识别 且若要修复只能 breaking change，就连 QX 作者都技术性评价了 ShadowTLS 不如 REALITY，图我懒得找了你们找一下 贴 出来吧。
然而对于 VLESS 协议，由于其设计改变了传统 TLS 的分层边界。若要实现支持，需要对上游 TLS 库（如 OpenSSL/BoringSSL）进行定制化修改，这意味着后续无法直接跟随上游更新，增加整体 TLS 子系统的复杂性与安全评估成本。
说完原理了简单说一下实现吧，实际上现在连 Golang 实现的 XTLS 都不需要修改 TLS 库，C 系语言那更是不需要了，怎么 Surge 能实现 ShadowTLS 但到了 XTLS 就各种困难了？ 就算是 REALITY，客户端也只需要改个 TLS Client Hello 的 session id，外加接管证书验证，所需代码也就几十行而已。
https://t.me/projectXtls/2526 Surge 开发者很明显是偏向于应用层面而不是底层，当我看到他说需要大改 TLS 库时我就眼前一黑了，因为 XTLS 根本不需要改 TLS 库了，读缓冲区数据的话 Golang 都可以 reflect，C 系语言更是一大堆方法，而 REALITY 只需改个 CH 的 session id 和接管证书验证，前者小改一下就行没有任何难度，对于 C 甚至可能不用改，后者是本来就有的功能
真的太简单了没啥好说的，评价一下“不同开发者持续提出新的设计思路，并在开放讨论与相互借鉴中推动技术演进”吧，我觉得任何人如果尊重我的 credit 那么抢跑我的想法/设计我也无话可说，至少别反踩几脚我啊，比如 XDRIVE 刚被偷家我甚至觉得可以去借鉴交流下，然而 Surge 刚支持的 AnyTLS 是怎么做的？VLESS 一开始的设计就预留了 Seed、我喊了五年了人尽皆知，TLS in TLS 就是我写的 PoC 还跟隔壁吵了半年，Vision Seed 的 PR 也一直挂着在等 GFW 反应，结果 AnyTLS 在仓库里反踩 Vision 两脚、丝毫不提 Seed，你这，我，哎，甚至还成我没能力和 GFW 的科研团队正面交火了，挺搞笑的就。
不过即使是这样我还是觉得 AnyTLS、AnyREALITY 的出现是好事，不然现在只剩直连而 VLESS 又一家独大的话那也确实挺吓人的，不是技术上没能力交火而是肉体上没能力，我也说过 真心希望任何隔壁都好好活着，只是你说我不好那我肯定也要跟你 battle 一下而不会当做没看到，有人开了头结果引来我的对线那也很正常，性格使然，而我在这里最主要的目的还是建设自己想建设的东西、推动自己该推动的东西，想让自己的人生更有价值，就这样吧。
连续剧 又更新了，半个月前 Surge 发了个“关于 VLESS 协议的说明”，我说“正在开始写一篇文章简评一下”，
鸽了半个月终于写了当时正值“中转/专线”开始被全面清退，这也是我早就 预言 过的，
毕竟治不了国外还治不了国内吗，不过当它真的来的时候也还是有唇亡齿寒之感吧，然而由于 Surge 生态长期对直连主流 VLESS 生态 嗤之以鼻 且 更加推崇 “中转/专线”生态，于是被 反噬 了，Surge 论坛出现了大量要求支持 VLESS 的贴子但被删除，恰逢作者忙于装修而疏于更新，推特上评价工人的推文被众人套模板 反评 作者，推特也改为了“仅允许经确认的关注者查看”，于是 Surge 发了两篇声明，一是上面那个说明，二是订阅期自动延期策略以安抚群怨，叠上上个月的 Mac 端 bug 差点需续费才能修复事件导致的群怨，这是事件背景，海豚测速、在花频道、小声逼逼 等频道亦有报道这样的结果有必然也有偶然：当一群人习惯于躺在围绕着喝茶营销高价、但实际上价不配位的假 omakase 构筑的“谜之优越感”舒适区，没有什么真东西却出于“迷之优越感”而经常看不上包括但不限于专注于反审查、不断积极更新的另一群人，狼没来时随便蹦跶互喷，掩耳盗铃自欺欺人，但当狼真的来时必然会最先翻车，这种事大清已经经历过了；偶然的是 Surge 最近的口碑确实挺差的，即使没有 VLESS 事件，其它一些操作也挺迷的，
群人数确实也越来越少了，上面那三个频道发过很多我就不多说了；另一个原因是 Sukka 去年在 Surge 群表示 VLESS 要完了、“除夕夜来波大的”，更加坚定了 Surge 不支持 VLESS 的信心，比如有人问为什么不支持 VLESS 时某管理员称“到时候就知道了”、“时间站在我们这边”，结果现在“中转/专线”先凉得更彻底，虽然也波及到了直连但直连还是更具韧性聊完人性的东西该聊技术了，我只是想评论一下就比如说
我们知道 XTLS 功能之一是允许内层 TLSv1.3 流量“裸奔”，它带来的特性一是很明显的性能最强，且可以通过 ReadV、Splice 等技术进一步增强；二是后续流量完全就没有“TLS in TLS”，比如代理浏览器时后续流量特征完全符合浏览器的特征，尤其是会有 h2 小包等，且不会出现其它代理协议中非常明显的“h2 小包双重加密”，也能避免异常的“显著包长度增长”、“持续超过 MTU 限制”（引用 Naive 的说法）等，这些是它独一无二的价值所在。
当然也会存在一些问题但“降低了安全边界的可验证性”？这么说吧，ECH 都知道吧，XTLS 几乎就是 ECH，同样是只加密了 inner TLS 的握手部分，而后续 TLSv1.3 已经是 AES 加密过的，除非 AES 被破解了否则没人能破解出内容，它和 ECH 解决的是同一个问题，当然 ECH 解决不了的问题它也解决不了；标题中还提到了 EIP，即 Encrypted IP，很简单，这是因为实际上你就是在用你服务器的 IP 来“加密”真正的目标 IP，
这下被你提前用上了。提一嘴下个月计划 #26 (comment)既然 XTLS 是把 inner TLS 拼接到自身，那么有没有一种可能我们还能先和一个白名单网站握手，随后把自身的 TLS 流量拼接上去？这是和 XTLS 孪生的想法，
这句话我本来要写到 REALITY 文章里的但不小心鸽了，我说我早就想出 ShadowTLS 这种东西了吧，即使有很多证据但还是有人“调侃”，现在这么一想是不是就很丝滑了？显然你还要有额外的东西来加密自身前面的 TLS 握手，但当时我并没有自己写个“土制加密”的打算就先鸽了，加上消失了一段时间，回来的时候已经有人写了 ShadowTLS，那我更喜欢另辟蹊径，比如说有没有一种可能我不写“土制加密”了，我直接复用 TLS 的整个握手和加密，我研究了一下可行，于是就有了 REALITY，它也是第一个这样做的协议，并且最大程度遵循了 TLSv1.3 的语义以方便升级，比如升级了抗量子。最离谱的地方是什么呢，同样是“跨层设计”、且 Surge 已经支持的 ShadowTLS 才是真正降低了你数据的安全性，因为它传输数据靠的并不是 TLS 而是 连前向安全、客户端配置安全都没有的 SS，你可以说 inner 流量大多是 TLS 但那也不全是啊，就算是 TLS 也至少能解出你的 SNI 吧？而 XTLS 是用 TLS 把 inner SNI 加密了、且确认流量是 TLSv1.3 才会“裸奔”。这不是很明显的双标吗？ 何况 ShadowTLS v3 由于设计不当 已被精准识别 且若要修复只能 breaking change，就连 QX 作者都技术性评价了 ShadowTLS 不如 REALITY，
图我懒得找了你们找一下 贴 出来吧。说完原理了简单说一下实现吧，实际上现在连 Golang 实现的 XTLS 都不需要修改 TLS 库，C 系语言那更是不需要了，怎么 Surge 能实现 ShadowTLS 但到了 XTLS 就各种困难了？ 就算是 REALITY，客户端也只需要改个 TLS Client Hello 的 session id，外加接管证书验证，所需代码也就几十行而已。
真的太简单了没啥好说的，评价一下“不同开发者持续提出新的设计思路，并在开放讨论与相互借鉴中推动技术演进”吧，我觉得任何人如果尊重我的 credit 那么抢跑我的想法/设计我也无话可说，至少别反踩几脚我啊，比如 XDRIVE 刚被偷家我甚至觉得可以去借鉴交流下，
然而 Surge 刚支持的 AnyTLS 是怎么做的？VLESS 一开始的设计就预留了 Seed、我喊了五年了人尽皆知，TLS in TLS 就是我写的 PoC 还跟隔壁吵了半年，Vision Seed 的 PR 也一直挂着在等 GFW 反应，结果 AnyTLS 在仓库里反踩 Vision 两脚、丝毫不提 Seed，你这，我，哎，甚至还成我没能力和 GFW 的科研团队正面交火了，挺搞笑的就。不过即使是这样我还是觉得 AnyTLS、
AnyREALITY的出现是好事，不然现在只剩直连而 VLESS 又一家独大的话那也确实挺吓人的，不是技术上没能力交火而是肉体上没能力，我也说过 真心希望任何隔壁都好好活着，只是你说我不好那我肯定也要跟你 battle 一下而不会当做没看到，有人开了头结果引来我的对线那也很正常，性格使然，而我在这里最主要的目的还是建设自己想建设的东西、推动自己该推动的东西，想让自己的人生更有价值，就这样吧。