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.

[RPRX]

多年以来即使是金融级别的互联网应用也依赖于 TLS，致使我们认为 TLS 是足够安全的，而完全忽视了证书链攻击的风险，本文是为了敲响警钟

根据 #519 泄露出来的文件，可以看到 GFW 这类国家级别的攻击者确实尝试过通过大规模安装根证书的方式来进行 MITM，这便是 TLS 的根本弱点

针对此次泄露出来的文件，我在 Project X Channel 已有过一些解读，比如 https://t.me/projectXtls/1029 和 https://t.me/projectXtls/1032

1. 针对 TLS 的 MITM 等尝试普遍存在，前段时间 Xray 也收到了针对 REALITY 的“抽样式攻击尝试” Suppress "REALITY localAddr: X DialTLSContext" Logs XTLS/Xray-core#5066 ，这样的 log 只有在收到“真证书”时才会出现（因为此时 REALITY 进入了模仿 Spider 的模式），“they don't add any value” 的反馈表明它是抽样的、并未影响使用
2. GFW 针对明文 HTTP 的分析、注入能力已经非常完善，再次证明了完全禁止公网明文 HTTP 的必要性 Web Panels like 3X-UI are leaking an unimaginable amount of passwords and private keys to the GFW #448
3. 实锤了省墙等地区墙的存在 警惕 SNI 白名单地区隐蔽的大规模“降级攻击” / Watch out for hidden mass "downgrade attacks" in SNI whitelisted areas #254 (comment)
4. 实锤了 GFW 早就会针对翻墙的个人进行监控、追踪，而不一定直接封你 警惕 SNI 白名单地区隐蔽的大规模“降级攻击” / Watch out for hidden mass "downgrade attacks" in SNI whitelisted areas #254 (comment)

关于“监控”的部分符合内鬼早就透漏出来的信息，倒不怎么令人意外，关于 MITM TLS 的部分更加值得关注，因为这涉及到了“解密出明文”的根本问题

群里讨论了安装根证书然后 MITM 的问题，并不是说 GFW 在无差别地干这件事，那肯定不可行，因为肯定还有没这个根证书的设备，附带伤害太高，有别的国家试验过了
但是这并不代表定向爆破不可行，比如说 GFW 偶尔挑一条连接来测试，发现连接没断就可以知道在某些连接上是可行的，有需要的时候再对你进行定向爆破

就像中转机场的威胁模型还停留在十年前的“GFW 只在边境”，实际上省墙识别不出 SS 吗？当然可以，没到非封不可的时候而已，现阶段来说拿你密码来解个密收益更高
就不要幻想 GFW 不能拿到你密码或者拿到你密码后不会解密这种事了，以后再多泄露点文件出来你直接成小丑，甚至如果把这两件事结合起来，先解密再 MITM TLS 都行

放弃幻想，直面现实，只要存在攻击的可能性就必然有对应的攻击存在，还是那张图 https://t.me/projectXtls/1020

#519 (comment) 讨论了“分享链接加上 pin 证书”的事情，但由于它是非强制的、可选的东西，并没有解决根本问题，根本方法是在标准上抛弃 TLS：

1. 对于不经过 CDN 的场景，都应当使用 REALITY 这类不依赖 CA 证书的 TLS-like 协议，以强制性标准的方式解决问题
2. 对于经过 CDN 的场景，都应当使用 VLESS Encryption 以确保被代理的内容不被 CDN 偷窥以及不被 GFW MITM 出明文

而且几乎只有这两个协议同时专注于防范“客户端配置泄露”，而 SS、VMess 等协议从未考虑过该问题 #254 ，这也是我接下来要说的：

总是有人通过臆想来说 GFW 不会怎么怎么样什么的，不如想想为什么我要把协议设计成这样，为什么要防证书链攻击，为什么要防客户端配置泄露，为什么要防监控等，因为我们五年前就得到了很多内部信息，我也多次提过，所以后来我开发的协议全部都有针对性

总有人觉得没被封就等于协议是安全的，然后硬是在那里用不够安全的加密还沾沾自喜，比如中转 SS，或者 ShadowTLS+SS 什么的，殊不知老大哥在注视着你，那确实够“安全”的，还在用偷个客户端配置就能解密的“加密协议”，不知道在想什么，建议使用 VLESS Encryption https://t.me/projectXtls/1020

Shadowsocks 等协议不引入“前向安全”的理由之一是“被代理的内容几乎都是 TLS，顶多泄露个 SNI”，当然泄露 SNI 本身也不好，但如果 TLS 也不再可靠以至于可以被 GFW 解密或 MITM 出明文呢？比如 GFW 偷到客户端配置后，被代理的 X25519 可以被先记录、后解密，或者复合式 MITM

目前由于 GFW 早已将全随机数外观列入黑名单，“直接过墙”的 SS 等协议在中国几乎没有了，但“中转机场”几乎全是 SS 协议，它缺乏

客户端配置安全：若攻击者拿到了客户端配置，无法解密以前、以后的通信内容，无法对以后的通信进行 MITM（中间人攻击）。 这个安全概念没有前向安全那么常见，不知道是不是代理领域独一份，但它非常重要，因为通过读取剪切板、输入法上传、通讯软件分享、国产反诈手机等方式想拿到你的客户端配置可以说是没有难度。

前向安全：若攻击者拿到了长期密钥（一般指服务端的），无法解密以前的通信内容。一般来说对以后的通信内容也无法直接解密，而是只能 MITM。 实现前向安全一般基于 TLS/REALITY ECDHE 或抗量子的“双方临时密钥交换”，但是会增加 1-RTT。

比如 SS 2022/AEAD（以及基于它们的 ShadowTLS）、VMess 采用对称 PSK 的设计，并没有实现客户端配置安全、前向安全，都是看似加密但实际上没有任何保障，GFW 拿到了你手机上的配置后，甚至还能直接解密你电脑等其它设备的流量（即使只是 SNI 也方便了监控）。 还有一些协议是拿到客户端配置即可 MITM，只能说是一言难尽。

相较于针对 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

1. Attempts such as MITM attacks targeting TLS are widespread. Recently, Xray also detected "sampling-style attack attempts" targeting REALITY (Suppress "REALITY localAddr: X DialTLSContext" Logs XTLS/Xray-core#5066). Such logs only appear when "genuine certificates" are received (as REALITY enters Spider emulation mode). The feedback stating "they don't add any value" indicates these were isolated incidents that did not impact usage.
2. The GFW's capabilities for analyzing and injecting plaintext HTTP traffic are now highly sophisticated, further proving the necessity of completely banning public plaintext HTTP Web Panels like 3X-UI are leaking an unimaginable amount of passwords and private keys to the GFW #448
3. Confirmed the existence of regional firewalls like the "Provincial Wall" 警惕 SNI 白名单地区隐蔽的大规模“降级攻击” / Watch out for hidden mass "downgrade attacks" in SNI whitelisted areas #254 (comment)
4. Solid evidence that the GFW has long monitored and tracked individuals circumventing the firewall, without necessarily blocking them outright. 警惕 SNI 白名单地区隐蔽的大规模“降级攻击” / Watch out for hidden mass "downgrade attacks" in SNI whitelisted areas #254 (comment)

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."

The group discussed installing root certificates for MITM attacks. This doesn't mean the GFW indiscriminately does this—that would be impractical since many devices lack the root certificate, causing too much collateral damage. Other countries have already experimented with this approach.
But this doesn't mean targeted brute-force attacks are impossible. For instance, the GFW might occasionally test a single connection. If it finds the connection remains uninterrupted, it can determine the method works on certain connections and then launch targeted brute-force attacks against you when needed.

It's like the threat model for transit airports is still stuck in the decade-old "GFW only operates at the border" mindset. Can't provincial firewalls actually identify SS? Of course they can. It's just not worth blocking yet. Currently, decrypting your passwords yields higher returns.
Stop fantasizing that the GFW can't obtain your passwords or won't decrypt them once acquired. Leak more files in the future and you'll become a laughingstock. Combine these two tactics—first decrypt, then perform MITM TLS attacks—and you're set.

Abandon illusions and face reality: Where there's potential for attack, corresponding attacks exist. See this diagram: https://t.me/projectXtls/1020

#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:

1. For scenarios not using CDNs, protocols like REALITY that bypass CA certificates should be mandated as a standard solution.
2. For scenarios using CDNs, VLESS Encryption should be adopted to prevent CDNs from snooping on proxied content and to block GFW MITM attacks from exposing plaintext.

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:

Some people always speculate that the GFW won't do this or that. Instead, consider why I designed the protocol this way—why protect against certificate chain attacks, why guard against client configuration leaks, why defend against surveillance. Because we obtained extensive internal information five years ago, and I've mentioned this repeatedly. That's why every protocol I developed later has targeted countermeasures.

Some people mistakenly believe that just because a protocol hasn't been blocked, it must be secure. They then proudly use insecure encryption methods like relaying through SS or ShadowTLS+SS. Little do they realize Big Brother is watching. That's "secure" enough—still using "encryption protocols" that can be decrypted by stealing client configuration. I don't know what they're thinking. I recommend using VLESS Encryption: https://t.me/projectXtls/1020

**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.

Client Configuration Security: If an attacker obtains your client configuration, they cannot decrypt past or future communications and cannot perform MITM (man-in-the-middle) attacks on future communications. This security concept is less common than forward secrecy—perhaps unique to the proxy domain—but it's critically important. After all, obtaining your client configuration is remarkably easy through methods like reading clipboards, input method uploads, messaging app sharing, or domestic anti-fraud phones.

Forward Secrecy: If an attacker obtains the long-term key (typically the server key), they cannot decrypt past communications. Generally, they also cannot directly decrypt future communications but can only perform MITM attacks. Forward secrecy is typically achieved using TLS/REALITY ECDHE or quantum-resistant "mutual ephemeral key exchange," though this adds 1-RTT.

For instance, SS 2022/AEAD (and ShadowTLS based on them) and VMess employ symmetric PSK designs that fail to implement client configuration security or forward secrecy. These appear encrypted but offer no actual protection. Once the GFW obtains your phone's configuration, it can even directly decrypt traffic from your computer and other devices (even SNI alone facilitates surveillance). Some protocols allow MITM attacks simply by obtaining client configurations. It's beyond words.

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:

Encryption protocol comparison	VLESS Encryption	VLESS REALITY/TLS	Shadowsocks 2022/AEAD/ShadowTLS, VMess AEAD
Traffic appearance	native / xorpub / random	TLSv1.3	random / ShadowTLS (Handshake message length differs significantly from compromised sites, thus not labeled as TLSv1.3)
Suitable for direct proxy bypass	❌	✔️	❌
Client configuration security: Client configuration leaks cannot decrypt past or future traffic (proper authentication prevents MITM on future traffic)	✔️	✔️	❌
Forward secrecy: Server private key leaks cannot decrypt past traffic (but can MITM future traffic unless mitigated by dynamic configuration updates)	✔️	✔️	❌
Increased RTT	0-RTT	1-RTT (can achieve 0-RTT with XHTTP, MUX, or other multiplexing)	0-RTT (ShadowTLS adds 1-RTT)
Post-quantum key exchange and authentication	✔️	✔️ (However, compared to REALITY, TLS is vulnerable to certificate chain attacks if certificates aren't pinned, and TLS currently lacks quantum-resistant certificates)	❌ (No key exchange; encryption and authentication rely on fixed PSKs, thus lacking client configuration security/forward secrecy)
No strict synchronization required	✔️	✔️	❌, SS AEAD ✔️
Perfect replay protection	✔️	✔️	❌ (Incomplete protection after restart; SS AEAD is even more "replay-vulnerable")
No need for multiple decryption attempts to identify users	✔️	✔️	❌, SS 2022 ✔️
No additional AEAD length required	✔️	✔️	❌, VMess ✔️
Actual performance	XTLS bypasses secondary encryption on proxied TLSv1.3 (largest share)	Same as above, XTLS auto-penetrates external encryption layers, auto-performs ReadV/Splice	Indiscriminate AEAD encryption/decryption overhead
Easily usable on transport layers like XHTTP, WS	✔️ (VLESS standard defaults to XUDP, auto UoT Migration)	Deeper than transport layer; upper layers also default to XUDP, auto UoT Migration	Original SS designs lack UoT, requiring external solutions; VMess's default UoT has flaws; Xray defaults to XUDP

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.

[ZhangSir9901]

对土匪不要抱有幻想。

Don't be under any illusions about bandits.

[oole345]

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.

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.

[RPRX]

诡辩罢了，一个很简单的问题：由于 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.

[RPRX]

并且对于 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.

[mehdifirefox]

Just 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.

[gfw-killer]

It'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?

[Cl-He-O]

@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.

[AkinoKaede]

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.

[gmvp3]

小白请教，所以单跳出国的需要Reality + TLS + VLESS Encryption吗？

Newbie here—so does a single jump out of the country require Reality + TLS + VLESS Encryption?

[oole345]

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.