Project X Channel

以及我看到很多人好奇 REALITY 和 ShadowTLS+SS2022 的区别，简单解释就是 REALITY 是 ECDHE 的真正 TLS，若客户端配置泄露了也不会威胁到数据安全；而 ShadowTLS+SS2022 是对称密码 PSK，若客户端配置泄露了可以解密过往及以后的所有流量。对比协议要看它们的底层原理，并不是它们似乎做了类似的事情就是相同、可互相替代的东西。

获悉近期 Stash 和 Loon 支持了 REALITY，其分享链接标准在 https://github.com/XTLS/Xray-core/discussions/716 此外 REALITY 结合 XHTTP 时默认是 stream-one，就是一个最简单的 HTTP 请求，可以支持一下

💬New comment onXray-core#3260 Add VLESS seed configurations by @RPRX 计划是这个版本就 REALITY 抗量子更新 + Vision Seed，下个版本就 ECH + VLESS Encryption，然后 Windows TUN 和 JSON 订阅 ~~搞个无脑的 JSON 订阅给机场和小白用，分流爱好者狂喜，MXGA！~~ Reply to this message to post a comment on GitHub.

Project X Channel pinned «Xray-core v25.3.6 已正式推出，XHTTP: Beyond REALITY 更至第四版 XHTTP 服务端需要及时升级至该版本，以支持新版 XHTTP 客户端。 请支持一个 REALITY NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2 如果你有余力，请支持一个 Project X NFT：https://opensea.io/assets/ethereum/0x5…»

Xray-core v25.3.6 已正式推出，XHTTP: Beyond REALITY 更至第四版 XHTTP 服务端需要及时升级至该版本，以支持新版 XHTTP 客户端。 请支持一个 REALITY NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2 如果你有余力，请支持一个 Project X NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1 Xray 接下来的重心转向 Vision Seed & VLESS Encryption，Windows Tun & GUI Client，以及 ECH 和 REALITY 抗量子更新。

尝试使用 MITM / h2c:// + domain fronting 绕过近期的 DoH 封锁

💬New comment onXray-core#4283 Add Datagram transport by @RPRX 我研究了一下 quic-go 和其 h3 的 EnableDatagrams，它可以被转译为 h2，Nginx 应该支持转发，只是不知道 ~~CF~~ CDN 是否支持 目前如果想做到 UDP 包走 XHTTP/3 datagram 是完全可行的，鉴于 UDP 可能被 Q 还可以允许配置为只让 UDP 包走 XHTTP/3 虽然路由也能做这件事，还有如果只想让少量 UDP 包走 XHTTP/3，还得把被代理流量的 UDP 443 禁了 Reply to this message to post a comment on GitHub.

💬New comment onXray-core#4458 Questioning the Security of the REALITY Protocol by @RPRX 发现“鉴定为有病”那句被 yuhan 折叠了，我说下为什么火气这么大吧，首先这个人在 Xray 群就已经在说 REALITY public key 应当公开然后大谈主动探测了，**当时频道已经明确说了它不应公开，结果这个人还注册个小号假正经地一通分析最后 Summary “不如 TLS”** 谁看了都火大，然后我总结一下，他第一点的错误在于他 不仅要先把 REALITY public key 和 IP 地址一起公开**，还要拿弱配置 short id 的 REALITY 和拉满配置的 TLS 双向认证比，哪有这么比的？**双向认证又不是强制的，你要开这个就把 short id 等同地配成 2^64，或者给 REALITY 也开 TLS 双向认证**，此外他提到的 ID-forward secrecy 我努力理解为他认为认证必须是 certificate-based 才好，不是，这只是认证又不涉及加密，**纵览全文他似乎总是觉得有个 certificate-based 的认证就多了不起、对加密有什么谜之加成，然而加密安全性上大家都是 ECDHE，反而引入 certificate 机制导致了引入了更多的攻击面，如证书链攻击，本质上远不如固定的 pin 安全 他的第二点是 先假设客户端 key_share 对应的临时私钥泄露了**，然后说此时 REALITY 能被 MITM，不是，**你客户端临时私钥都泄露了，流量都能全解密了，哪个 TLS 不能被 MITM？ 他一开始说 TLS 签了个 finished 能避免被 MITM，以及谜之提及双向认证，被我反驳后改为了 TLS 双向认证都是真证书能避免被 MITM，又被我反驳后最终承认这种情况下 TLS 也能被 MITM，**这又体现出了他以为 certificate-based 和双向认证会对加密安全性有谜之加成、没有仔细研究 TLSv1.3 的加密机制、且不知道 TLS 抗量子指的是什么** 然后现在呢？@gaungap 发现自己的分析和结论有严重问题后就装死不再回复，也不把错误的 Summary 改一下 还有 REALITY 比 TLS 更安全是因为前者默认能防证书链攻击，他一句也没提。**是 CA 想攻击你很难还是往你电脑里加个根证书很难？** Reply to this message to post a comment on GitHub.

💬New comment onXray-core#4458 Questioning the Security of the REALITY Protocol by @RPRX > > 提 clientKey 那位朋友倒不是在反驳，只是这个名字确实不如 password 简单粗暴直接，我都这么命名了应该没人再想着公开了吧 > > 确实，这样子应该就能堵上某些人的嘴了吧——毕竟应该不会有人笨蛋到把自己家的wifi密码贴到大街上然后说WPA2不安全吧？ 这是个非常好的类比，之前我保留它的命名为 public key 就是因为 它在不同客户端之间是共用的，且它们之间无法对彼此 MITM，这与 WiFi 密码的效果完全一致，连上的也是服务端“同一个网络” 而 short id 可以对标网卡 MAC 地址，甚至还比后者多了两个字节，这两个值都是能任意改的，服务端想验证就相当于 MAC 白名单 Reply to this message to post a comment on GitHub.

💬New comment onXray-core#4458 Questioning the Security of the REALITY Protocol by @RPRX 群友也别马后炮说什么这种 issue 就该直接关，这种东西留着不辨的后果就是真的有小白会信，日后反复拿出来恶心人 @gaungap 这位哥们已经不敢说话了，**你要是还觉得自己占理你就出来走两步，要是发现自己错了就道歉、修改小作文，别玩不起** "What I see is a lot of people without a cryptography background making pointless attacks" 这真的不是在说他自己吗 Reply to this message to post a comment on GitHub.

https://github.com/XTLS/Xray-core/releases/tag/v25.3.3

💬New comment onXray-core#4458 Questioning the Security of the REALITY Protocol by @RPRX > As @Abjust also mentioned, the name 'password' doesn't imply that these need to be paired for authentication. I think it would be better to rename it to 'clientKey'. 别 imply paired 了，歧义就出在 paired 上，**就该把服务端视作黑箱，而客户端只知道 password，别管它是什么，按密码保管就行** Reply to this message to post a comment on GitHub.