Repository navigation
TLS / QUIC 不应被继续视为可靠的加密方式，以及针对 TLS in Shadowsocks/TLS 的复合式 MITM，最后对于 VLESS Encryption 的介绍 / TLS/QUIC should no longer be considered a reliable encryption method, and compound MITM attacks targeting TLS in Shadowsocks/TLS. Finally, an introduction to VLESS Encryption. #526
Description
Activity
- changed the title
[-]TLS / QUIC 不应被继续视为可靠的加密方式，以及针对 TLS in SS/TLS 的复合式 MITM，最后对于 VLESS Encryption 的介绍[/-][+]TLS / QUIC 不应被继续视为可靠的加密方式，以及针对 TLS in SS/TLS 的复合式 MITM，最后对于 VLESS Encryption 的介绍 / TLS/QUIC should no longer be considered a reliable encryption method, and compound MITM attacks targeting TLS in SSL/TLS. Finally, an introduction to VLESS Encryption.[/+]on Sep 16, 2025 对土匪不要抱有幻想。
Don't be under any illusions about bandits.
Reacted by 墨染月, QuincySnow, GD-Slime, Echemon and showgood163For years, even financial-grade internet applications have relied on TLS, leading us to assume it is sufficiently secure while completely overlooking the risks of certificate chain attacks. This article serves as a wake-up call.
REALITY is truly amazing 😆 ! I suggest the author submit an RFC to the IETF 😏; otherwise, using it only for censorship circumvention would be a waste.
"Implanting root certificates" resembles "modifying client configurations"—both are unsolvable problems. The key difference is that the latter requires continuous subscription modifications and persistent MITM attacks, while the former only needs a single successful implementation to enable ongoing MITM attacks.
What you said is quite accurate: attacking trusted certificates is indeed a weakness of TLS. REALITY is essentially a form of Public Key Pinning, but PKP can also be applied in regular TLS, so fundamentally, there's no conflict. I do appreciate the practical contribution here. Implementing REALITY would raise the bar for attackers in real-world scenarios, especially against compromised CAs. It's just that claiming 'TLS should no longer be considered a reliable encryption method'… a bit like shouting: 'NP = P' or 'RSA is broken' on Hacker News for attention.
Reacted by ᡠᠵᡠᡳ ᡠᠵᡠ ᠮᠠᠨᡩ᠋ᠠᠨ, QuincySnow, 墨染月 and Cl-He-OReacted by RPRX, black23eep and LMFutureReacted by Levein.Zhang, black23eep and iosmanthus诡辩罢了，一个很简单的问题：由于 pin 证书对于 TLS 是可选的，你如何保证所有实现都强制 pin 证书？该用法有没有占万分之一？
REALITY 是采用协商出的“认证密钥”对“随机证书”进行签名以验证服务端的身份，相较于 pin 证书，该过程为强制的，占 100%
这与 Web-Panel 是否应从源头禁止公网明文 HTTP 是类似的问题，但更严重，因为 pin 证书的概率比不使用明文 HTTP 的概率低得多
That's just sophistry. A very simple question: Since pinned certificates are optional for TLS, how do you ensure all implementations enforce pinned certificates? Is this usage even one in ten thousand?
REALITY employs a negotiated “authentication key” to sign a “random certificate” for server identity verification. Unlike pinned certificates, this process is mandatory and occurs 100% of the time.
This parallels the debate over whether Web-Panel should block plaintext HTTP at the source—but it's more critical, since pinned certificates are far less common than unsecured HTTP.
Reacted by oole345并且对于 TLS 而言，pin 证书在实践上存在一些阻碍，因为证书经常更换、不一定由谁签发，如果是直连自己的服务器那还可以预测，而如果是 CDN 那就五花八门、不定什么时候就换了。虽然套 CDN 会不可避免地使用 TLS，但若要防止 CDN 偷窥通信内容会启用 VLESS Encryption 这样的可靠加密，从而同时防止了 GFW 对内层 TLS 进行 MITM，本质上还是对单纯 TLS 的不信任。
一个相对有意义的改变可能是，比如说对 Xray-core 而言，内置所有的根证书而不信赖系统根证书，但还是那个问题，我只能确保 Xray-core 这样做但管不到别的代理客户端，此外如果有任意一个 CA 与 GFW 合作签发假证书（CNNIC 事件），还是难以防御。
Moreover, for TLS, certificate pinning faces practical obstacles because certificates frequently change and may not be issued by a predictable authority. While pinning is manageable for direct connections to your own servers, CDNs present a diverse landscape where certificates can change unpredictably at any time. While using a CDN inevitably involves TLS, enabling robust encryption like VLESS Encryption prevents CDNs from snooping on communication content. This also thwarts MITM attacks on inner TLS layers by the GFW, essentially reflecting a fundamental distrust of plain TLS.
A relatively meaningful change could be, for example, for Xray-core to embed all root certificates and not rely on system root certificates. But the same problem remains: I can only ensure Xray-core does this, but I can't control other proxy clients. Furthermore, if any CA collaborates with the GFW to issue fake certificates (as in the CNNIC incident), it remains difficult to defend against.
Reacted by showgood163 and LMFutureJust liking is not enough
I wanted to thank you for all the hard work you've been doing for years.
I hope one day you can write your own project from scratch, completely for yourself and completely secure. More protocols. Faster.
Reacted by GFW-Killer and 墨染月Reacted by RPRXReacted by oole345 and baiiyluIt's a good reminder, Chinese people with a Huawei phone or other Chinese devices/browsers should be worried about it, but some of them are trolling and laughing, I don't understand them.
I also have a question, When the Trust Store is infected and GFW can MITM, can Encrypted VLESS + XTLS Partial Encryption migrate the risk too? or should only use the fully encrypted mode?
Reacted by showgood163@RPRX 一点小的思考：如果攻击者有能力植入根证书，那整个设备都应被视为是不可信的。在这种情况下，攻击者当然也能修改设备上的客户端，从而 MITM 所有连接，我不认为针对 TLS 和其它协议的 MITM 有本质上的区别。
A minor consideration: If an attacker can implant a root certificate, the entire device should be considered untrustworthy. In such a scenario, the attacker could naturally also modify the client software on the device to perform MITM attacks on all connections. I don't believe there's any fundamental difference between MITM attacks targeting TLS and those targeting other protocols.
Reacted by 秋野かえで and MatseoiReacted by RPRXUnder the Certificate Transparency, certificates are trusted only if they are added to CT log. The log is a publicly queryable Merkle tree, making it virtually impossible to tamper with.
Once a mis-issuance is reported, the CA in question is quickly removed from the trusted root by big technology companies.
Reacted by ShotoZhao, rest-api-v2 and 墨染月Reacted by RPRX小白请教，所以单跳出国的需要Reality + TLS + VLESS Encryption吗？
Newbie here—so does a single jump out of the country require Reality + TLS + VLESS Encryption?
Under the Certificate Transparency, certificates are trusted only if they are added to CT log. The log is a publicly queryable Merkle tree, making it virtually impossible to tamper with.
Once a mis-issuance is reported, the CA in question is quickly removed from the trusted root by big technology companies.
Absolutely right, CT is essentially a variant of certificate pinning, with the distinction that it relies on a distributed PKI to enforce it. Public key cryptography relies on the trustworthiness of participants' public keys; without that, the entire construction collapses.
That's just sophistry. A very simple question: Since pinned certificates are optional for TLS, how do you ensure all implementations enforce pinned certificates? Is this usage even one in ten thousand?
However, allow me a friendly reminder: @RPRX has pointed out that what you're doing is just sophistry: apart from browsers, which implementation actually enforces your SCT verification? So my advice is still the same: don't argue too much with the greatest anti-censorship warrior, RPRX, it's a bit childish. 😆
Anyway, I can't wait to see RPRX's RFC, seriously! REALITY is exactly the kind of protocol that the IETF folks should take a good, hard look at. This is a truly revolutionary protocol.
Reacted by RPRX, Kyle, black23eep and LMFutureapart from browsers, which implementation actually enforces your SCT verification?
All App on Apple's platform that use Apple's embedded TLS stack. Enabling Certificate Transparency verification is mandatory by Apple.
https://support.apple.com/en-us/103214
https://developer.apple.com/documentation/bundleresources/information-property-list/nsrequirescertificatetransparencyGoogle is a little slow to act, but it’s still very easy to enable Certificate Transparency verification, and perhaps this option will be forced to be enabled soon. If you pay attention to financial applications, you will find that many banking applications have already implemented certificate transparency by writing their own code.
https://developer.android.com/privacy-and-security/security-config#certificateTransparency
So my advice is still the same: don't argue too much with the greatest anti-censorship warrior, RPRX, it's a bit childish.
If possible, I would consider filing a civil lawsuit against you to compensate for the mental damage caused to me by such disgusting words.
Reacted by oole345 and KyleReacted by RPRXReacted by oole345, Kyle and black23eepIf possible, I would consider filing a civil lawsuit against you to compensate for the mental damage caused to me by such disgusting words.
Disgusting? I'd say it’s juuust right~ I've seen things far more disgusting and absurd. 😆
Google is a little slow to act, but it’s still very easy to enable Certificate Transparency verification, and perhaps this option will be forced to be enabled soon. If you pay attention to financial applications, you will find that many banking applications have already implemented certificate transparency by writing their own code.
Yes, in fact, SCT verification has already become quite widespread. For details, see this 2019 paper: https://dl.acm.org/doi/10.1145/3319535.3345653. That doesn't stop some smartass from always coming up with new ideas, right 😄?
Moreover, there's an immutable CT Log List available: https://www.gstatic.com/ct/log_list/v2/log_list.json. In GoLang, a user could try to check the SCTs within
tls.VerifyConnectioncallback queries the list. And this lib might help the user parse the CT logs: https://github.com/google/certificate-transparency-go.Reacted by RPRX, black23eep and LMFuture@oole345 不知道你从何而来的优越感，多次抬杠加嘲讽，毫无素质且令人作呕，你为反审查贡献过任何东西吗？为什么不敢用大号说话？对我批评伊朗面板明文 HTTP 一事怀恨在心？Blocked，就像我早该做的那样，给他点赞的人也是绝了，这种人也配？
@AkinoKaede TLS in TLS 还是所谓的“骗流量”吗？那这个不更是“骗流量”了？
对于“植入根证书”并利用它这件事，有不少工具就是基于这个原理比如 #454 、“深信服”等，你们所谓的 enforced CTV 此时在哪呢？
甚至 iOS 上一堆代理软件利用 MITM 来“去广告”，似乎最新的 26 版本才禁止，由于应用广泛，后续是否会重新开放也不知道
@oole345 I have no idea where you get your sense of superiority from. Your repeated nitpicking and mockery are utterly uncultured and disgusting. Have you ever contributed anything to anti-censorship efforts? Why don't you dare speak up with your main account? Still holding a grudge over my criticism of Iran's plaintext HTTP panels? Blocked—just as I should have done long ago. And the people who gave him a thumbs-up? Unbelievable. Does someone like this even deserve it?
@AkinoKaede Is TLS-in-TLS still considered “traffic deception”? Then isn't this even more of a “traffic deception”?
Regarding “implanting root certificates” and exploiting them—numerous tools operate on this principle, like #454 and “Sangfor.” Where's your so-called enforced CTV now?
Even on iOS, tons of proxy apps use MITM to “ad-block.” It seems the latest iOS 26 version finally banned it. Given how widespread these apps are, who knows if Apple will ever allow them back.
Reacted by black23eep@RPRX 一点小的思考：如果攻击者有能力植入根证书，那整个设备都应被视为是不可信的。在这种情况下，攻击者当然也能修改设备上的客户端，从而 MITM 所有连接，我不认为针对 TLS 和其它协议的 MITM 有本质上的区别。
A minor consideration: If an attacker can implant a root certificate, the entire device should be considered untrustworthy. In such a scenario, the attacker could naturally also modify the client software on the device to perform MITM attacks on all connections. I don't believe there's any fundamental difference between MITM attacks targeting TLS and those targeting other protocols.
@Cl-He-O 我在正文中早已说明了两者的区别，“植入根证书”只需成功一次即可有需要时随时 MITM、放个冷枪，而“修改客户端配置”需要持续修改订阅、持续 MITM，否则会造成代理不可用，且极易被发现，这就是它们在本质上的区别
本质上 CA 机制是信任“一个范围”，攻击者只需加入这个范围，而“客户端配置”只是信任“单点”，
当然对于 SS 这种对称 PSK 那也没了I've already explained the difference between the two in the main text: “Implanting root certificates” only needs to succeed once to enable MITM attacks or cold-shooting whenever needed, while “Modifying client configuration” requires continuous subscription changes and persistent MITM, otherwise it causes proxy unavailability and is easily detected—that's their fundamental distinction.
Fundamentally, the CA mechanism trusts “a scope”; attackers need only infiltrate that scope. “Client configuration” trusts only “a single point”
though with SS's symmetric PSK, that trust is also nullified.45 remaining items
小白问一下，那我客户端和服务端都更新了最新版本，会默认使用VLESS Encryption的特性吗？
Hey, just wondering. If I update both my client and server to the latest versions, will they automatically use the VLESS Encryption feature?
小白问一下，那我客户端和服务端都更新了最新版本，会默认使用VLESS Encryption的特性吗？
不会，需要手动配置。
No, it requires manual configuration.
小白问一下，那我客户端和服务端都更新了最新版本，会默认使用VLESS Encryption的特性吗？
不会，需要手动配置。
那我有必要在xtls-rprx-vision + reality 的基础上开启VLESS Encryption吗？
Is it necessary for me to enable VLESS Encryption on top of xtls-rprx-vision+reality?
那我有必要在xtls-rprx-vision + reality 的基础上开启VLESS Encryption吗？
一般来说没有必要，除非你偷的网站尚未支持 X25519MLKEM768 但你又想要抗量子
Generally, it's not necessary unless the site you're stealing from doesn't yet support X25519MLKEM768 but you want quantum-resistant encryption.
I'm more worried about more global trends of things like Microsoft Pluton and future of bootloaders in general. If all computers become like phones, with locked bootloader and no available alternative operating systems, then what? China/Russia/Iran not gonna install Microsoft's spyware, they will roll their own, then what? What you left is more iron curtain as everyone will just makes their own hardware with own backdoors, and then what you gonna be left with?
AFAIK pluton TPM can be disabled.
@RPRX, your presence here has gotten too toxic. I have blocked your account. Your bombastic writing style and self-important attitude were annoying but tolerable. Your willingness to use insults, however, and your failure to engage with others in good faith, are not compatible with a healthy community.
Speaking to you as one human being to another: I think you will find more success and happiness if you change your approach. It must be clear to you that your way of arguing online is not effective—not at persuading people of your ideas nor at winning them to your side. The good that your posts contain (and there is some) gets lost in the cloud of hurt feelings and hostility that they tend to provoke.
We've had this discussion already two years ago. Can it be that you have not improved your ability to communicate in that time? You must be able to predict, by now, the kind of reaction you will get, dealing with others the way you do? It really appears that you are more interested in picking fights than in exchanging ideas or learning from others.
In this thread and elsewhere I've seen a persistent lack of good faith. If someone posts a question about evidence for TLS MITM, it does not necessarily mean that they think TLS MITM is not a realistic threat, nor that they think it is not an attack worth defending. Neither does it mean that they think your ideas are far-fetched, or that you are overreacting. It means only what it says: that the other person feels there may be a gap in their understanding, one that others may be in a position to help with, and they are asking for information in order to establish common understanding and have a more productive discussion. People are willing to talk about the topics you insist they are not: it's just that they are not willing to do it in an environment of intimidation, where they can expect to have their point misunderstood no matter how carefully they choose their words.
No one can say I have not been patient with you. I have tried to be understanding and give you an opportunity, even having heard of disruptions in other communities. But enough is enough: my own thresholds for irritation and wasting time have been exceeded. If, in the future, you find yourself asking, why do I feel persecuted wherever I go, why do others not accept my valuable ideas, remember that more than once, people have told you directly why, and take their words to heart. I hope for a happy reconciliation in the future.
Reacted by Weltolk, Vinicius Fortuna, gus, t2kDWjhAvB and IllusionLieReacted by RPRXX, Lumière Élevé, ECJRO, Nikita Korotaev , wuwkos and 闲人一枚Reacted by fbion and Mr ConterReacted by RememberOurPromise和两年前的 #254 (comment) 一样，对于 #526 (comment) 的那些冷嘲热讽式的、旨在激怒我的那些发言，你并没有任何反应或行动
如果你及时对这些人采取了反应或行动，就不需要我去处理这些人，毕竟按我的原则只会“以其人之道还治其人之身”
别人怎样对我我就怎样对别人，别人会冷嘲热讽那我也会，结果你只会拎出来我说我怎么怎么样
其它的我就不列举了，@wkrp 你只会盯着我，这是大家都看得到的事实，你或许想成为一个公平的裁判，但你离合格还差很远
Reacted by ECJRO and Nikita KorotaevReacted by Weltolk- locked as off topic and limited conversation to collaborators
on Sep 30, 2025
多年以来即使是金融级别的互联网应用也依赖于 TLS，致使我们认为 TLS 是足够安全的，而完全忽视了证书链攻击的风险，本文是为了敲响警钟
根据 #519 泄露出来的文件，可以看到 GFW 这类国家级别的攻击者确实尝试过通过大规模安装根证书的方式来进行 MITM，这便是 TLS 的根本弱点
针对此次泄露出来的文件，我在 Project X Channel 已有过一些解读，比如 https://t.me/projectXtls/1029 和 https://t.me/projectXtls/1032
关于“监控”的部分符合内鬼早就透漏出来的信息，倒不怎么令人意外，关于 MITM TLS 的部分更加值得关注，因为这涉及到了“解密出明文”的根本问题
#519 (comment) 讨论了“分享链接加上 pin 证书”的事情，但由于它是非强制的、可选的东西，并没有解决根本问题，根本方法是在标准上抛弃 TLS：
而且几乎只有这两个协议同时专注于防范“客户端配置泄露”，而 SS、VMess 等协议从未考虑过该问题 #254 ，这也是我接下来要说的：
Shadowsocks 等协议不引入“前向安全”的理由之一是“被代理的内容几乎都是 TLS，顶多泄露个 SNI”，当然泄露 SNI 本身也不好，但如果 TLS 也不再可靠以至于可以被 GFW 解密或 MITM 出明文呢？比如 GFW 偷到客户端配置后，被代理的 X25519 可以被先记录、后解密，或者复合式 MITM
目前由于 GFW 早已将全随机数外观列入黑名单，“直接过墙”的 SS 等协议在中国几乎没有了，但“中转机场”几乎全是 SS 协议，它缺乏
相较于针对 SS 等协议还要偷到客户端配置，代理协议直接使用 TLS 会导致如果 MITM 成功的话，简单的两次 MITM 基本可以解密内层 TLS，问题更严重，攻击者完全可以二次 MITM 且没有理由不这么干，即“TLS / QUIC 不应被继续视为可靠的加密方式，以及针对 TLS in Shadowsocks/TLS 的复合式 MITM”
（存在一些情况可以规避被代理的 TLS 被 MITM，如果浏览器不信任系统 CA，或者发起内外两层 TLS 的是不同的设备，但只有一个被植入了根证书）
“植入根证书”有点像“修改客户端配置”，这个无解，但不同之处在于后者必须持续修改订阅、持续 MITM，而前者只需成功一次就可以随时 MITM
最后介绍下刚出的 VLESS Encryption 吧（REALITY 大家都已经很熟悉了，无需介绍），它比 SS、VMess 等协议安全很多：
以上对比图截自 XTLS/Xray-core#5067 （如果要翻译成英文可以翻译原表格），更详细的 Spec 以及对比也在那里
For years, even financial-grade internet applications have relied on TLS, leading us to assume it is sufficiently secure while completely overlooking the risks of certificate chain attacks. This article serves as a wake-up call.
Documents leaked via #519 reveal that state-sponsored attackers like the GFW have indeed attempted MITM attacks by mass-deploying root certificates—exposing TLS's fundamental vulnerability.
Regarding these leaked documents, I've previously provided analysis on Project X Channel, such as: https://t.me/projectXtls/1029 https://t.me/projectXtls/1032
The surveillance aspect aligns with information leaked by insiders long ago, so it's not particularly surprising. The MITM TLS part warrants greater attention, as it touches on the fundamental issue of "decrypting plaintext."
#519 (comment) discusses "sharing links with pin certificates," but since this is optional and non-mandatory, it doesn't solve the core issue. The fundamental solution is to abandon TLS in standards:
Moreover, these are virtually the only protocols simultaneously focused on preventing "client configuration leaks." Protocols like SS and VMess have never addressed this issue #254 — which brings me to my next point:
**One reason protocols like Shadowsocks don't implement "forward secrecy" is the assumption that "proxied content is almost always TLS, so at worst only SNI gets leaked." While SNI leakage is bad enough, what if TLS itself becomes unreliable—to the point where the GFW can decrypt or MITM it into plaintext? For instance, if the GFW steals client configurations, proxied X25519 traffic could be recorded first and decrypted later, or subjected to compound MITM attacks.
Currently, since the GFW has long blacklisted all random-looking traffic, protocols like SS that "directly bypass the wall" are virtually nonexistent in China. However, "relay airports" almost exclusively use the SS protocol, which is lacking.
Compared to protocols like SS, which require stealing client configurations, proxy protocols directly using TLS face a more severe issue: a successful MITM attack can decrypt the inner TLS layer with just two MITM attempts. Worse still, attackers can perform secondary MITM with no reason not to—meaning "TLS/QUIC should no longer be considered reliable encryption methods, and compound MITM attacks against TLS in Shadowsocks/TLS are possible."
(Some scenarios can mitigate MITM attacks on proxied TLS: if the browser doesn't trust the system CA, or if the inner and outer TLS layers originate from different devices—provided only one has a planted root certificate).
"Implanting root certificates" resembles "modifying client configurations"—both are unsolvable problems. The key difference is that the latter requires continuous subscription modifications and persistent MITM attacks, while the former only needs a single successful implementation to enable ongoing MITM attacks.
Finally, let's introduce the newly released VLESS Encryption (REALITY is already well-known and requires no introduction). It offers significantly greater security than protocols like SS and VMess:
The above comparison chart is taken from XTLS/Xray-core#5067 (if you need to translate it into English, you can translate the original table). More detailed specifications and comparisons are also available there.