💬 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-5615081269 ：

REALITY 的本质是服务端 MITM，同时也是真正的 TLSv1.3，**精妙地继承了 TLSv1.3 的前向安全等一揽子安全设计同时还强制 pin**，这是 REALITY 与类似目标的其它协议的最大的不同之处，当然既然已经是 MITM 了那么服务端肯定要升级才能支持新的加密套件比如 X25519MLKEM768，并非 dyhkwong 所述的“协议设计者在设计协议之初未考虑到 TLS 的潜在变化”，**毕竟你不可能在一开始就支持未来才会出的加密套件**，dyhkwong 在其叙事中屡次基于刻意偏见把 REALITY 描述成“已经进行并且将来也会不得不持续进行破坏性变更”却丝毫不提 REALITY 的本质及安全特性，且虽然 REALITY 的认证依赖 CH 中的 X25519 但就算不依赖，**仅“看起来正常的 MITM”这一条就需要你更新服务端以支持新的加密套件**，至于依赖 CH 中的 X25519 进行认证也是 REALITY 的安全设计即 **GFW 仅拿到客户端配置无法对你 MITM**，而绝大多数别的“土制协议”是从未考虑过这一点的，这些也是 dyhkwong 不会告诉你的，甚至 REALITY 抗量子更新第二弹 加的 ML-DSA-65 更是将这一安全设计提前覆盖到了后量子时代

再说说指纹的问题，所有人都知道 nekohasekai 自那场搞笑“论战”过后就没有跟进过包括其 fork 的 REALITY 仓库在内的几乎任何更新，若不是他们后来统一用 Mihomo 的 uTLS fork 附带 REALITY ~~那估计这辈子你都看不到 sing-box 服务端支持 REALITY X25519MLKEM768~~，[Xray-core v25.5.16](https://github.com/XTLS/Xray-core/releases/tag/v25.5.16) 写的是“所以服务端一定要及时升级，避免新版客户端连不上”、“等一两个月后其它网站陆续开始支持了，大家的服务端早就升级、兼容了”但我也不说这个点了，Xray v25.5.16 版本开始的 Chrome 指纹就是带 X25519MLKEM768 的，也就是说 Xray 生态的服务端若不及时升级就连不上，那大家猜猜那些客户端 trim 掉 X25519MLKEM768 主要是为了兼容哪家的旧版客户端呢？甚至我觉得这还不是最大的重点，**最大的重点是都过去一年了还搞这种奇怪的指纹是要 [恶心谁](https://t.me/projectXtls/3539?comment=5242816)？不复当年 uTLS 出个指纹问题就想顺带把 REALITY 说死那次了？所以我总是说吧有些人它就是屁股歪，若非要说是“为了兼容”那么若没有这种指纹纵容，反而所有服务端早就升级了，甚至在协议作者明确说不能搞这种奇怪的指纹后某些人愣是不改，亘古未有啊，那我只能在服务端把这种指纹过滤掉以确保至少 Xray 搭出来的 REALITY 不会受此影响，~~都是这个世界的错~~**

Reply to this message to post a comment on GitHub.