https://t.me/projectXtls/953 评论区文摘

太厉害了，只有reality会有拿到key被解密的风险是吗？

你这什么理解能力，不是被解密是被 MITM，且前提是拿到 REALITY 客户端配置+未来的量子计算机。TLS 也是这样，且不用拿到客户端配置，因为就没有。SS、VMess 更是拿到客户端配置的话，现在就能解密以前、以后的所有流量，不用等量子计算机。

不是的，我是说只是reality需要配置吗？像是vless xtls rprx vision 自建web受这个拿到key的影响并且需要配置吗？

你用 TLS 的话，现在还没抗量子证书，等死就好了

没有啊，最新xray core搭配tls1.3不是已经默认支持防量子解密了吗？而且已经有抗量子配置了就不存在等死了

MITM 是量子计算机把你 TLS 证书给破解了，无关 X25519MLKEM768

REALITY 这次的更新就是相当于上抗量子证书，TLS 还没有

明白了，那意思还是要上rwality才能享受了，如果能像上次X25519MLKEM768一样全协议适配就好了，因为真的没有动力去折腾，加上人在墙外只是为了隐私去代理的，隐私又包含防量子解密

那只能上reality才能了

因为 TLS 证书的换代要很长时间才能铺开，要往设备里加根证书，要很久，但 REALITY 是我们自己的协议，随便造

明白了，感谢科普，祝一切顺利

自主可控

太激进了，考虑这么长远😂

@Fangliding

(这个是未来的技术攻击未来的连接 而且前提是客户端公钥泄露 直到有量子计算机真的可以用公钥逆向私钥之前 无法被MITM (如果是后量子密钥交换 现在的数据在未来也是安全的)

有没有扛量子第三弹

可能几年后会有，如果到时候 TLS Client Hello 能多塞点东西

👍求解答，之前看有讨论说可以通过两条独立连接实现MITM，这个会做吗？

下个月可能，主要是为了彻底解决 post-handshake records 问题

👍👍👍 牛逼

这下真遥遥领先了

Thank you dear RPRX
Could you please inform us about the process of VLESS Encryption
As it's necessary for CDN(TLS or non-TLS) and non-TLS setups

net4people/bbs#448 (comment)

VMess encryption is static password + symmetric encryption, and you can decrypt all previous and future traffic once you have the client password
VLESS encryption is quantum-resistant key exchange + symmetric encryption, and it is forward-secure. I can also make it so that RTT is not sacrificed.

net4people/bbs#448 (comment) (14 Feb 2025) (5 months ago)

VLESS encryption was partially written last year and will be released within this month

net4people/bbs#448 (comment)

I do plan to restrict VLESS without any encryption after VLESS encryption is launched

And what is your opinion about the community ideas for VLESS Encryption

1. A partial encryption; VLESS can have a partial encryption that detects known encrypted traffics (e.g. TLS), and encrypt only the plaintext parts (e.g. TLS ClientHello) and Unknown traffics to prevent double encryption and waste of resources

2. Availability of secure but lightweight encryptions like Ascon for Mobile and IoT devices

恶意提问，不利于团结的话不要说，禁止合订，历史文件不具有现实意义

恶意提问，不利于团结的话不要说，禁止合订，历史文件不具有现实意义

we need lightweight as much as it's possible please

恶意提问，不利于团结的话不要说，禁止合订，历史文件不具有现实意义

Those ideas are reasonable

A partial encryption for known encrypted traffics like TLS, as TLS only leaks the dest IP, Port and SNI to the MITM(GFW or CDN or both)
Or a lightweight to not make pressure on low-end devices and consume less battery
Or both

I didn't say to not support a good encryption like AES and ChaCha20 or full encryption mode
I have no bad intentions

@gfw-killer 我只是在玩梗，事情要一件件做，Vision Seed 和 ECH 都眉清目秀的，下下个版本的重点是这俩

只看最后一级证书的算法是否不准确 reality就返回一个单级证书 但是平时网站返回的是一个完整证书链 三级证书的自己的公私钥和授权签名算法都不一样 输出整个长度这样好一点吧 比如谷歌的虽然全链ECC但是它整个证书链也有五千多(cf的也是全链ECC但是只有两千五btw 不知道长在哪)

恶意提问，不利于团结的话不要说，禁止合订，历史文件不具有现实意义

REALITY 做不到 0-rtt
这样 HK CN2-GIA 约等于美西了
本来想用 MUX 配合路由规则将就一下，发现会有特征

无意间发现了 xtls-rprx-switch
我是新来的，不利于团结的话我来说：这么好的东西为啥没实现？

will switch eta ?

只看最后一级证书的算法是否不准确 reality就返回一个单级证书 但是平时网站返回的是一个完整证书链 三级证书的自己的公私钥和授权签名算法都不一样 输出整个长度这样好一点吧 比如谷歌的虽然全链ECC但是它整个证书链也有五千多(cf的也是全链ECC但是只有两千五btw 不知道长在哪)

之前就想过直接输出长度，但实现不了，peerCertificates 里就一个证书，而 verifiedChain 里应该还包含 root

反正根据观察 RSA 的证书消息一般都 4000+，刚好够，ECDSA 的不够

恶意提问，不利于团结的话不要说，禁止合订，历史文件不具有现实意义

REALITY 做不到 0-rtt 这样 HK CN2-GIA 约等于美西了 本来想用 MUX 配合路由规则将就一下，发现会有特征

无意间发现了 xtls-rprx-switch 我是新来的，不利于团结的话我来说：这么好的东西为啥没实现？

目前配合 XHTTP 就行了，Vision Seed 也会支持它

只看最后一级证书的算法是否不准确 reality就返回一个单级证书 但是平时网站返回的是一个完整证书链 三级证书的自己的公私钥和授权签名算法都不一样 输出整个长度这样好一点吧 比如谷歌的虽然全链ECC但是它整个证书链也有五千多(cf的也是全链ECC但是只有两千五btw 不知道长在哪)

之前就想过直接输出长度，但实现不了，peerCertificates 里就一个证书，而 verifiedChain 里应该还包含 root

反正根据观察 RSA 的证书消息一般都 4000+，刚好够，ECDSA 的不够

peerCertificates 里不止一个 只是最后一级域名证书的位置不一定 如果放在第一个的话 按 if len(cert.DNSNames) == 0 → continue 这样的话那第一个被遍历到之后就会直接输出导致它只会输出最后一级证书的长度 如果放在最后的话就可以正常遍历到 又或者不continue强制让它遍历完再输出也是完整长度

peerCertificates 里不止一个

我这里测试都是只有一个 不知道啥原因

按之前的说法golang是不会自动补全上级证书的 没fullchain只有一层的话验证都过不了

按之前的说法golang是不会自动补全上级证书的 没fullchain只有一层的话验证都过不了

反正我测试那个域名用 WireShark 看是长度 4000 左右的证书消息，但 peerCertificates 里只有一个长度 2000 左右的证书，且没有第二个证书，你测试看看

哪个域名

哪个域名

这个不方便说，总之你找些域名测试下吧，如果能直接输出所有证书总长度当然就更好了

@Fangliding 至少 ./xray tls ping 证书那块不是循环吗，我就没见过输出过第二个证书

#4933 (comment)

还有我本来以为 RSA 的证书，整个链加起来基本有 4000+，经反馈得知不是，ML-DSA-44 的话少 800 字节，兼容的网站更多

不过治标不治本，我看那些 ECC 的都是 1200+ 而已，没必要降低安全标准，还是等 FN-DSA 吧

根据网站证书需求：

注意 ML-DSA-65 的签名为 3309 字节，所以目前需选择 RSA 证书的目标网站，而不能选择 ECDSA 证书的目标网站，但这在未来不会是问题，因为未来抗量子签名的证书也会很长，虽然现在 TLS 还没有公开的这种证书，所以 REALITY 又一次走在了时代前沿；还有，我没选 ML-DSA-44 是觉得来都来了不差这八百字节；此外，FIPS 206 的 FN-DSA 签名较短，但还没有出草案。

似乎，github.io的证书符合要求呢：

$ xray tls ping github.io
TLS ping:  github.io
Using IP:  185.199.110.153:443
-------------------
Pinging without SNI
Handshake succeeded
TLS Version:  TLS 1.3
TLS Post-Quantum key exchange:  true (X25519MLKEM768)
Certificate chain's total length:  4645 (certs count: 3)
Cert's signature algorithm:  SHA256-RSA
Cert's publicKey algorithm:  RSA
Cert's allowed domains:  [*.github.io *.github.com *.githubusercontent.com github.com github.io githubusercontent.com www.github.com]
-------------------
Pinging with SNI
Handshake succeeded
TLS Version:  TLS 1.3
TLS Post-Quantum key exchange:  true (X25519MLKEM768)
Certificate chain's total length:  4645 (certs count: 3)
Cert's signature algorithm:  SHA256-RSA
Cert's publicKey algorithm:  RSA
Cert's allowed domains:  [*.github.io *.github.com *.githubusercontent.com github.com github.io githubusercontent.com www.github.com]
-------------------
TLS ping finished

另外，似乎openlm.ai亦满足需求：

$ xray tls ping openlm.ai
TLS ping:  openlm.ai
Using IP:  185.199.110.153:443
-------------------
Pinging without SNI
Handshake succeeded
TLS Version:  TLS 1.3
TLS Post-Quantum key exchange:  true (X25519MLKEM768)
Certificate chain's total length:  4645 (certs count: 3)
Cert's signature algorithm:  SHA256-RSA
Cert's publicKey algorithm:  RSA
Cert's allowed domains:  [*.github.io *.github.com *.githubusercontent.com github.com github.io githubusercontent.com www.github.com]
-------------------
Pinging with SNI
Handshake succeeded
TLS Version:  TLS 1.3
TLS Post-Quantum key exchange:  true (X25519MLKEM768)
Certificate chain's total length:  2573 (certs count: 2)
Cert's signature algorithm:  SHA256-RSA
Cert's publicKey algorithm:  RSA
Cert's allowed domains:  [openlm.ai www.openlm.ai]
-------------------
TLS ping finished

@MoRanYue github.io 可以，openlm.ai 不行，因为证书链总长度需要 3500+

恶意提问，不利于团结的话不要说，禁止合订，历史文件不具有现实意义

REALITY 做不到 0-rtt 这样 HK CN2-GIA 约等于美西了 本来想用 MUX 配合路由规则将就一下，发现会有特征

无意间发现了 xtls-rprx-switch 我是新来的，不利于团结的话我来说：这么好的东西为啥没实现？

什么特征？

什么特征？

MUX 后 TLS in TLS 特征：

• MUX 连接内第一个 TLS 有特征
• 若这条 MUX 连接比较空闲，后续的 TLS 也会有特征。如果墙是全量分析的话就会被捕获到，只是不知道假阳性率咋样

非得填充不可，也就是要魔改 mux.cool 协议

非得填充不可，也就是要魔改 mux.cool 协议

并非不兼容，mux.cool 协议结构不小心可扩展，XUDP 和 Global ID 就是这么来的