💬 New comment on Xray-core#6477 Xray-core v26.7.11 与 mihomo v1.19.28 REALITY 不兼容，连接全部提示 authentication failed
by @RPRX

https://github.com/ExclaveNetwork/Exclave/issues/480#issuecomment-5647030654 依旧稳定发挥了 dyhkwong 基于屁股说话只说一半、断章取义误导观众的传统艺能：

首先又是上次掰扯过的问题，虽然当时风扇确实没给我说，更没有他们脑补的“我授意”什么的，**但 Xray-core v26.2.6 确实也写了“v26.2.6 包含一些 v26.1.23 新增功能的配置项变更、重要修复，请及时升级 Xray-core 以及 GUI 客户端”，我没改，web archive 自己去看，能别狗叫了不？** 其次又是跟 drownrat 学的车轱辘句式，他们口口声声的“漏洞”指的是当时没几个人用的 pcs 参数，**妄图以极小搏极大来糊弄过去“那些个客户端让本能用上 X25519MLKEM768 的用户降级到 X25519”的问题，毕竟后者影响面可是基于 REALITY 庞大用户基数的大多数非 Xray 客户端，抛开影响面谈安全问题/漏洞是诡辩，试图掩盖真正的核心问题是无耻**，无视我推动的那么多安全策略却拿没几个人用的参数来论证“不配”更是可笑，甚至我根本就没干那事，~~学到了 Sukka 和 drownrat 的精髓说是~~，提醒升级的 release notes 倒是我写的，后面 pcs 也是我强推才流行的

> 中间人拿到客户端配置对用户 MITM 属于用户不按照操作方式使用导致的自食其果，不属于协议问题。即使如此，基于 TLS 的协议仅拿到客户端配置仍然无法 MITM。REALITY 等魔改 TLS 认证流程的协议属于自己制造了别的协议不存在的问题再自己解决。

类似于“抛开影响面、抛开 release notes”的说话只说一半，~~这抛开不谈咋这么眼熟~~，**光说“制造了别的协议不存在的问题”却丝毫不提“解决了别的协议没解决的问题”，你那单纯套个 TLS 的协议是能妥善解决 SNI 白名单的问题还是说你要自签证书加 allowInsecure？甚至没我强推 pcs 的话这问题都没被摆到主流台面上来**，以前的 Trojan、现在的 AnyTLS 机场多流行这套组合你们也门清，至于自建，大概率又是“属于用户不按照操作方式使用导致的自食其果”，那问题是机场用户基本上是小白、自建用户基本上是大白，跟着教程甚至一键脚本冲就完了根本就不懂那些，**况且即使是 pin 证书也不如 REALITY 这类方案，它们虽然不完美但至少在持续进步，至于“中间人拿到客户端配置对用户 MITM”让用户自食其果，是你能保证用户的客户端配置不漏还是？以前说过很多可能性就不重复了，所以解决了这问题的协议它就是比没这解决问题的协议更先进**

最后终于到 trim 掉 X25519MLKEM768 的问题了，dyhkwong 口口声声辩护这一行为，~~“协议本身恶心”其实是“协议必须恶心”~~，**却没有告诉你 Go 程序使用 uTLS 的初衷就是“符合浏览器 Client Hello”，那你都 trim 掉了 X25519MLKEM768 你还是个 der 的浏览器 CH 啊这不搞笑吗？我说过就算回落到旧版 Chrome 指纹也比这强啊，他同样没有告诉你的是 Xray-core v25.5.16 即 REALITY 服务端支持 X25519MLKEM768 那一版开始，Xray 客户端的 Chrome 指纹就是默认指向带 X25519MLKEM768 的最新版，我们也没遇到什么大问题啊，官方尚且如此，第三方实现对齐官方行为不就行了，有什么必要留畸形的指纹？甚至一年后官方明确说了不能搞这种，一年多了还不能改？是为兼容还是实际上懂的都懂，他更没有告诉你的是客户端带上 X25519MLKEM768 而连不上旧版服务端在当时只是极少数，这就是为什么像 Xray 直接切新指纹本就完全可行**

Reply to this message to post a comment on GitHub.