💬 New comment on Xray-core#4458 Questioning the Security of the REALITY Protocol
by @RPRX

> 会敲那几个latex符号就是有 cryptography background 了吗

他自己是那么认为的，再设置个看似很 background 的头像，这就叫专业的小丑，瞎几把乱扯后就装死不敢正面回复，说他 end user 觉得自己比一群实现了 REALITY 的开发者都懂吧他又受不了

https://github.com/XTLS/Xray-core/commit/dde0a4f2729d9c56c0b7c7581b77d98f8f46e108 我给 REALITY publicKey 加了别名 password，**如果还有人理解不了就当 password 来理解**，以前没加是因为连傻子都知道节点信息不该泄露，然而他就是要把这玩意儿泄露了然后大谈主动探测，纯傻逼。还有 REALITY 公私钥的设计就是防止一旦客户端配置泄露了后能被 MITM 的，安全性拉满，这也是相较于 ShadowTLS+SS 的优势，还有一群人拿后者当宝呢

第二点就更加扯淡，TLS 客户端要生成一对临时 X25519，并把临时公钥填到 Client Hello keyshare，他的意思是如果对应的临时私钥泄露了，然后 REALITY 就能被 MITM，**然而问题是你临时私钥都泄露了，哪个 TLS 不能被 MITM？** 他前后两版说法的落脚点都是此时 TLS 不能被 MITM，纯属瞎说，后来他承认自己错了，经分析我认为他连近期的 TLS 抗量子都不知道是在干什么，就这垃圾水平

---

有些人说不喜欢我的“宣传风格”，原因就是我往往只写结论而不写分析过程，对此我已经表明，看不懂是自己菜，关我屁事

我喜欢只写结论不代表我是错的，同样他有模有样地扯一大段分析过程最后来个 Summary 也不代表他是对的，AI 就经常瞎扯淡

Reply to this message to post a comment on GitHub.

💬 New comment on Xray-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.

💬 New comment on Xray-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.

💬 New comment on Xray-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 on Xray-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 on Xray-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.

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

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 抗量子更新。

💬 New comment on Xray-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.

获悉近期 Stash 和 Loon 支持了 REALITY，其分享链接标准在 https://github.com/XTLS/Xray-core/discussions/716

此外 REALITY 结合 XHTTP 时默认是 stream-one，就是一个最简单的 HTTP 请求，可以支持一下

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

Xray-core 三月累积更新版本已 pre-release，主要包含大量针对 DNS 和 sockopt 的增强，以及其它几处修复，感谢各位贡献者

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

请支持一个 REALITY NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2

如果你有余力，请支持一个 Project X NFT：https://opensea.io/assets/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1

受宇宙射线影响，Switch PLUX 协议的代码已由 AI 自动写完，今晚就发

Based on Xray-core 的都支持，README 列出的 Happ、FoXray、Streisand 都是免费的，以及其它没列出的 iOS 客户端，大都是免费的

其实 XHTTP 作为客户端的话，三个 mode 的代码都很简单，用其它语言实现并不复杂，协议已经定型不会大改了，未来可能会加原生 UDP 特性支持，以及给 Nginx 加 QUIC 拥塞控制增强，也就是合理提速

疑似 CF free plan 的 gRPC 寄了，影响所有与 gRPC 相关的业务，XHTTP 可暂时切换至 packet-up mode，这下又赢了

遇事不决，packet-up

据悉 CF free plan 的 gRPC 已恢复正常，这次事件展现了 XHTTP 的鲁棒性，因为 packet-up 依赖的是最难以出问题的普通 GET / POST 请求，并且你还能选用 UDP 的 QUIC，只需搭建一个 XHTTP 全都会有

这两天我想到 packet-up 还可以出一个衍生的“统一上传”模式以减少 POST 请求数，但鉴于 CF gRPC 迅速恢复正常，暂无实现时间表

cf出问题赢一次 cf好了又要赢一次

这就是双赢