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

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

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

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

针对 TLS 的 MITM 等尝试普遍存在，前段时间 Xray 也收到了针对 REALITY 的“抽样式攻击尝试” https://github.com/XTLS/Xray-core/issues/5066 ，这样的 log 只有在收到“真证书”时才会出现（因为此时 REALITY 进入了模仿 Spider 的模式），“they don't add any value” 的反馈表明它是抽样的、并未影响使用
GFW 针对明文 HTTP 的分析、注入能力已经非常完善，再次证明了完全禁止公网明文 HTTP 的必要性 https://github.com/net4people/bbs/issues/448
实锤了省墙等地区墙的存在 https://github.com/net4people/bbs/issues/254#issuecomment-1562817397
实锤了 GFW 早就会针对翻墙的个人进行监控、追踪，而不一定直接封你 https://github.com/net4people/bbs/issues/254#issuecomment-1563161126

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

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

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

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

https://github.com/net4people/bbs/issues/519#issuecomment-3292618187 讨论了“分享链接加上 pin 证书”的事情，但由于它是非强制的、可选的东西，并没有解决根本问题，根本方法是在标准上抛弃 TLS：

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

而且几乎只有这两个协议同时专注于防范“客户端配置泄露”，而 SS、VMess 等协议从未考虑过该问题 https://github.com/net4people/bbs/issues/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 等协议安全很多：

以上对比图截自 https://github.com/XTLS/Xray-core/pull/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 https://github.com/net4people/bbs/issues/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

Attempts such as MITM attacks targeting TLS are widespread. Recently, Xray also detected "sampling-style attack attempts" targeting REALITY (https://github.com/XTLS/Xray-core/issues/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.
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 https://github.com/net4people/bbs/issues/448
Confirmed the existence of regional firewalls like the "Provincial Wall" https://github.com/net4people/bbs/issues/254#issuecomment-1562817397
Solid evidence that the GFW has long monitored and tracked individuals circumventing the firewall, without necessarily blocking them outright. https://github.com/net4people/bbs/issues/254#issuecomment-1563161126

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

https://github.com/net4people/bbs/issues/519#issuecomment-3292618187 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:

For scenarios not using CDNs, protocols like REALITY that bypass CA certificates should be mandated as a standard solution.
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 https://github.com/net4people/bbs/issues/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 https://github.com/XTLS/Xray-core/pull/5067 (if you need to translate it into English, you can translate the original table). More detailed specifications and comparisons are also available there.

Sep 16 '25 01:09 RPRX

对土匪不要抱有幻想。

Don't be under any illusions about bandits.

Sep 16 '25 03:09 ZhangSir9901

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.

Sep 16 '25 07:09 oole345

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

Sep 16 '25 11:09 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.

Sep 16 '25 11:09 RPRX

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.

Sep 16 '25 19:09 mehdifirefox

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?

Sep 16 '25 22:09 gfw-killer

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

Sep 17 '25 00:09 Cl-He-O

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.

Sep 17 '25 02:09 AkinoKaede

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

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

Sep 17 '25 12:09 gmvp3

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.

Sep 17 '25 14:09 oole345

apart 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/nsrequirescertificatetransparency

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.

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.

Sep 17 '25 16:09 AkinoKaede

If 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.VerifyConnection callback queries the list. And this lib might help the user parse the CT logs: https://github.com/google/certificate-transparency-go.

Sep 17 '25 17:09 oole345

@oole345 不知道你从何而来的优越感，多次抬杠加嘲讽，毫无素质且令人作呕，你为反审查贡献过任何东西吗？为什么不敢用大号说话？对我批评伊朗面板明文 HTTP 一事怀恨在心？Blocked，就像我早该做的那样，给他点赞的人也是绝了，这种人也配？

@AkinoKaede TLS in TLS 还是所谓的“骗流量”吗？那这个不更是“骗流量”了？

对于“植入根证书”并利用它这件事，有不少工具就是基于这个原理比如 https://github.com/net4people/bbs/issues/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 https://github.com/net4people/bbs/issues/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.

Sep 18 '25 08:09 RPRX

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

Sep 18 '25 08:09 RPRX

对于“植入根证书”并利用它这件事，有不少工具就是基于这个原理比如 https://github.com/net4people/bbs/issues/454 、“深信服”等，你们所谓的 enforced CTV 此时在哪呢？

甚至 iOS 上一堆代理软件利用 MITM 来“去广告”，似乎最新的 26 版本才禁止，由于应用广泛，后续是否会重新开放也不知道

MDM can be used to embed certificates and disable Certificate Transparency, but the prerequisite is that the device is enrolled in MDM as an enterprise-managed device.

In short, all operations require user authorization.

Using CAs for MitM isn't impossible, but the collateral damage is too high. Given that such attacks are reported within an hour or two, they can only be used once. They could potentially be used against high-profile targets like political activists and diplomats, but for most users, this isn't a significant concern.

Centralized WebPKI has its flaws, but it works well and doesn't require any specialized knowledge from the user.

Sep 18 '25 08:09 AkinoKaede

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?

@gfw-killer MITM 始于 TLS 握手阶段，XTLS 针对这个阶段有加密

你提出了一个很关键的场景即 Chinese devices，或者比如说你手机上有“反诈 App”或“内置反诈”，包括中国区 iPhone 等，它们都可以为国家级别的 MITM 开后门，从而使 CTV 什么的名存实亡，区别是 MITM 可以默默地获取所有明文，而“大规模上报”会造成流量异常

MITM attacks originate during the TLS handshake phase, and XTLS provides encryption specifically for this stage.

You've raised a critical scenario involving Chinese devices, such as phones with “anti-fraud apps” or “built-in anti-fraud features,” including iPhones in China, which can enable state-level MITM backdoors. This renders CTV measures largely ineffective. The difference is that MITM silently captures all plaintext data, while “mass reporting” would cause traffic anomalies.

Sep 18 '25 08:09 RPRX

@AkinoKaede

MDM can be used to embed certificates and disable Certificate Transparency, but the prerequisite is that the device is enrolled in MDM as an enterprise-managed device.

In short, all operations require user authorization.

然而上述 Chinese devices 就可以被认为是一类 MDM，我们面对的是国家级别的攻击者，且在中国境内非 Chinese devices 少得可怜

However, the aforementioned Chinese devices can be considered a form of MDM. We are facing state-level attackers, and non-Chinese devices are extremely scarce within China.

Using CAs for MitM isn't impossible, but the collateral damage is too high. Given that such attacks are reported within an hour or two, they can only be used once. They could potentially be used against high-profile targets like political activists and diplomats, but for most users, this isn't a significant concern.

Centralized WebPKI has its flaws, but it works well and doesn't require any specialized knowledge from the user.

即使不是 Chinese devices，https://github.com/net4people/bbs/issues/454#issuecomment-2680207378 等工具只能用一次吗？本文重点是“植入根证书”，也是泄露文件所揭示的 GFW 手段之一

Even if they aren't Chinese devices, can tools like https://github.com/net4people/bbs/issues/454#issuecomment-2680207378 only be used once? This article focuses on “implanting root certificates,” which is also one of the GFW tactics revealed by the leaked documents.

Sep 18 '25 09:09 RPRX

然而上述 Chinese devices 就可以被认为是一类 MDM，我们面对的是国家级别的攻击者，且在中国境内非 Chinese devices 少得可怜

The problem of the operating system acting as spyware is unsolvable.

Regardless of the encryption method, both the encrypted and decrypted data must appear in memory. The operating system has access to any memory of any user process.

In fact, by setting hooks before the encryption function and after the decryption function, arbitrary data can be decrypted without requiring a man-in-the-middle attack.

即使不是 Chinese devices，https://github.com/net4people/bbs/issues/454#issuecomment-2680207378 等工具只能用一次吗？本文重点是“植入根证书”，也是泄露文件所揭示的 GFW 手段之一

Inserting a root certificate is extremely difficult, and any attack by an individual requires a social engineering attack as a prerequisite.

Using a secure VPN is certainly a good mitigation measure, and this design is certainly beneficial.

But returning to TLS itself, TLS relies on reliable CAs as its security foundation. Installing a MitM certificate attack is not reliable proof that TLS is unreliable.

Sep 18 '25 09:09 AkinoKaede

@AkinoKaede

The problem of the operating system acting as spyware is unsolvable.

Regardless of the encryption method, both the encrypted and decrypted data must appear in memory. The operating system has access to any memory of any user process.

In fact, by setting hooks before the encryption function and after the decryption function, arbitrary data can be decrypted without requiring a man-in-the-middle attack.

如果这样说的话直接坐以待毙就行了，毕竟中国境内的 Chinese devices 就是无法解决的问题，我们能做的一切也只是提高攻击成本：

对于 SS 这类固定对称 PSK，拿到密码甚至能解密以前的所有流量，至少解密出个 SNI，或者对以后的流量“复合式 MITM”
对于 TLS 这类依赖大范围 CA 的，人家出厂预设后门证书，随时就能 MITM
对于 REALITY 这类相当于强制 pin 的，要么长期修改客户端配置要么长期上报协商出来的密钥，若路由器禁了后门还得另寻他法

If that's the case, we might as well just sit back and wait for disaster. After all, Chinese devices within China are an unsolvable problem. All we can do is increase the cost of attacks:

For fixed symmetric PSKs like Shadowsocks, obtaining the password could decrypt all past traffic, at minimum revealing the SNI, or enable "compound MITM" attacks on future traffic.
For TLS, which relies on widespread CAs, manufacturers can pre-install backdoor certificates, enabling MITM at any time.
For REALITY, which is essentially a forced PIN, you'd either need to constantly modify client configurations or continuously report negotiated keys. If routers disable the backdoor, you'd have to find another method.

Inserting a root certificate is extremely difficult, and any attack by an individual requires a social engineering attack as a prerequisite.

Using a secure VPN is certainly a good mitigation measure, and this design is certainly beneficial.

But returning to TLS itself, TLS relies on reliable CAs as its security foundation. Installing a MitM certificate attack is not reliable proof that TLS is unreliable.

任何有 root 权限的木马都能“植入根证书”，甚至拼多多都能直接把安卓 root 了

说“TLS is unreliable”就是因为已经有确实的证据表明 GFW 已经利用“Installing a MitM certificate”了，那还能放心地依赖 TLS 吗？

Any trojan with root privileges can "plant root certificates", and even Pinduoduo can directly root Android devices.

Claiming "TLS is unreliable" stems from concrete evidence showing the GFW has already exploited “Installing a MitM certificate". Can we still safely rely on TLS?

Sep 18 '25 10:09 RPRX

对于“植入根证书”并利用它这件事，有不少工具就是基于这个原理比如 https://github.com/net4people/bbs/issues/454 、“深信服”等，你们所谓的 enforced CTV 此时在哪呢？甚至 iOS 上一堆代理软件利用 MITM 来“去广告”，似乎最新的 26 版本才禁止，由于应用广泛，后续是否会重新开放也不知道

@RPRX FYI, that depends on the CT log verification strategy: https://httptoolkit.com/blog/chrome-android-certificate-transparency. If you need stronger security in anti-censorship software, you’ll need a stricter CT log verification policy — for instance, never trusting the system’s root CAs and instead maintaining your own CA without any Chinese providers.

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

This conclusion holds on the premise that the public keys trusted by REALITY are updated periodically. Similarly, the CT logs and CA certificates trusted by TLS can also be updated periodically. Therefore, I don’t think there is any fundamental difference between the two — essentially, it all comes down to regularly updating the public keys you trust.

You could argue that REALITY is effective at preventing CA hijacking attacks, but to ignore the existing anti-MITM mechanisms in TLS and leap to the conclusion that TLS is insecure seems downright reckless. Whether this is arrogance or ignorance, I won’t speculate further.

Sep 18 '25 10:09 ghost

@ucker125

@RPRX FYI, that depends on the CT log verification strategy: https://httptoolkit.com/blog/chrome-android-certificate-transparency. If you need stronger security in anti-censorship software, you’ll need a stricter CT log verification policy — for instance, never trusting the system’s root CAs and instead maintaining your own CA without any Chinese providers.

事实上我就是正在做这件事 https://github.com/XTLS/Xray-core/pull/5154#issuecomment-3299175884 ，至于其它软件会不会进行相同的改变，我管不了

Actually, I'm already doing this: https://github.com/XTLS/Xray-core/pull/5154#issuecomment-3299175884 As for whether other software will make the same changes, that's beyond my control.

This conclusion holds on the premise that the public keys trusted by REALITY are updated periodically. Similarly, the CT logs and CA certificates trusted by TLS can also be updated periodically. Therefore, I don’t think there is any fundamental difference between the two — essentially, it all comes down to regularly updating the public keys you trust.

REALITY 的预共享 x25519 密钥对并不用改，代理软件的订阅机制一天就能更新、覆写 N 次，所以说需要持续修改配置、持续 MITM

而“植入根证书”只需成功一次，此外被植入的根证书所签发的假证书根本不会上你 CT

REALITY's pre-shared x25519 key pair doesn't need to be modified. The proxy software's subscription mechanism can update and overwrite itself multiple times a day, requiring continuous configuration changes and persistent MITM attacks.

Meanwhile, “implanting root certificates” only needs to succeed once. Moreover, fake certificates signed by the implanted root certificate won't even appear on your CT.

You could argue that REALITY is effective at preventing CA hijacking attacks, but to ignore the existing anti-MITM mechanisms in TLS and leap to the conclusion that TLS is insecure seems downright reckless. Whether this is arrogance or ignorance, I won’t speculate further.

我的域名每次有证书被签发都会收到个 CT 邮件，然而这并没有让我用不了 https://github.com/net4people/bbs/issues/454 ，都说了重点是“植入根证书”而不是现有 CA 作恶

至于最后一句话，又来了，有些人不进行人身攻击等无关技术的言论是不是就浑身不舒服？我是真没兴趣对小号喷回去，Blocked

Every time a certificate is issued for my domain, I receive a CT email. However, this hasn't prevented me from using https://github.com/net4people/bbs/issues/454. The key point is "implanting root certificates", not malicious actions by existing CAs.

As for that last remark—here we go again. Do some people feel uncomfortable unless they resort to personal attacks and irrelevant non-technical comments? I genuinely have no interest in firing back at sock puppets. Blocked.

Sep 18 '25 10:09 RPRX

如果这样说的话直接坐以待毙就行了，毕竟中国境内的 Chinese devices 就是无法解决的问题，我们能做的一切也只是提高攻击成本：

对于 SS 这类固定对称 PSK，拿到密码甚至能解密以前的所有流量，至少解密出个 SNI，或者对以后的流量“复合式 MITM”

对于 TLS 这类依赖大范围 CA 的，人家出厂预设后门证书，随时就能 MITM

对于 REALITY 这类相当于强制 pin 的，要么长期修改客户端配置要么长期上报协商出来的密钥，若路由器禁了后门还得另寻他法

So I said it's a good mitigation, but it's just a mitigation.

任何有 root 权限的木马都能“植入根证书”，甚至拼多多都能直接把安卓 root 了

说“TLS is unreliable”就是因为已经有确实的证据表明 GFW 已经利用“Installing a MitM certificate”了，那还能放心地依赖 TLS 吗？

Regardless of how an untrusted certificate is installed, the fundamental problem isn't TLS itself, at least not primarily responsible, as TLS was designed to rely on certificate chains.

Criticisms of TLS and Web PKI are endless, but they remain limited to criticism, as it's currently impossible to build a system as easy to use as Web PKI that addresses the aforementioned issues.

An example from email is the battle between S/MIME and PGP. S/MIME, designed to rely on PKI, is simpler and easier to use, and therefore preferred by large companies. PGP relies on peer-to-peer communication, requiring users to attend offline meetups to exchange public keys before sending emails.

PGP enthusiasts might be able to tolerate frequent offline meetups, but for most internet users, it's difficult.

There's no point in continuing this discussion, so I won't add any further responses.

Sep 18 '25 11:09 AkinoKaede

在和你拥有同等执行命令权限(甚至比你更高权限)的设备上进行计算机技术的对抗是徒劳且愚蠢的

建议你了解一些主机安全的基础知识, 特别是rootkit/bootkit相关

如果你认为你的设备上的操作系统/应用软件(以及安全软件/杀毒软件等)是不可信(恶意)的, 同时你认为你的普通用户权限的行为(甚至是开源的), 可以对抗上述恶意行为, 那么这无异于发明了永动机的言论(这并非人身攻击, 而是对不了解主机安全的人尽快的直观的简短的表达出这种言论有多么荒诞)

你如何保证查询到的进程相关信息(比如xray.exe)是可信的? 这是可以被篡改的你如何保证查看的网络连接信息是正确的? 这是可以被隐藏和篡改的你如何保证查看的文件内容是真实的? 这是可以给你显示一个虚假的文件内容供你查看和修改, 实际操作系统中的文件是另一份内容

你如何确保拥有操作系统最高权限的恶意软件, 不会在reality加密/解密前进行hook从而轻易的得到明文数据? (通过用户态注入, ptrace, LD_PRELOAD, eBPF, 或内核态 kprobe/LKM等, 插在send/write之前, 和recv/read之后, 或直接挂在crypto库/协议握手函数上) 这甚至比你提到的对ss/tls进行攻击更加简单和稳定, 这种攻击无需任何MITM, 且不会造成任何除单个设备以外的范围性的影响, 也不会造成代理不可用, 一个用户态的代理软件对此不可能有任何防范手段

同理, 你如何确保REALITY协商出的认证密钥与临时密钥不被导出/上报?

你如何确保xray的二进制文件不被篡改(攻击者修改编译出一份恶意的xray二进制文件替换, 同时对hash校验相关函数/系统call进行hook, 返回正确的xray二进制文件的hash值), 从而在代码级别就:

在出站前把明文数据导出?
让客户端“接受任意服务端公钥/签名”, 或直接把验证函数永远返回成功?

它(恶意的软件/后门)还可以对RNG/握手下毒, 从而劫持随机数源或替换曲线运算实现, 让"临时密钥"可预测/可复算, 这种攻击, 一个用户态的代理软件不可能直接发现

它(恶意的软件/后门)还可以在本地直接劫持你其他软件设置的代理配置, 经过恶意的本地代理后再发送给本地的xray/reality入站

它(恶意的软件/后门)还可以篡改你的代理软件/协议所需要用到的操作系统提供的一切, 让你的pin/自带CA/二进制校验都形同虚设

它还可以:

重定向本地的流量, 在进入xray/reality之前拷贝一份数据, 再通过同样的配置解密
通过本地中继, 合法的解密出明文流量再发送给服务端, xray/reality如何发现这种行为?
在本地复用你的订阅通道下毒, 下发恶意的代理配置

最后的最后, 它还可以直接dump你设备上软件(浏览器, tg等)的内存/明文信息, 根本不需要对你展开攻击甚至是直接实时读取屏幕/键盘/鼠标/其他I/O设备并保存

...

这根本不是一个代理软件/协议应该考虑的事情, 你应该新开发一个主机安全软件项目

或许你很愤怒, 但我只是想指出你的基础知识的缺失

做为一款代理软件/协议, 你现在在研究的是操作系统安全

Sep 18 '25 11:09 Weltolk

Engaging in technical countermeasures against a device that possesses equivalent or even higher command execution privileges than yours is futile and foolish.

It is advisable to familiarize yourself with fundamental host security principles, particularly regarding rootkits and bootkits.

If you believe the operating system/application software (including security/antivirus tools) on your device is untrustworthy (malicious), yet you think actions performed under standard user privileges (even open-source ones) can counteract such malicious behavior, this is akin to claiming perpetual motion machines exist. (This is not a personal attack, but a concise, intuitive way for those unfamiliar with host security to grasp how absurd such claims are.)

How do you guarantee the reliability of queried process information (e.g., xray.exe)? This can be tampered with. How do you ensure the accuracy of network connection data? This can be concealed or altered. How do you verify the authenticity of file contents? Malicious actors could display fake file data for viewing and modification while the actual system file contains different content.

How do you prevent malware with highest OS privileges from hooking before reality encrypts/decrypts to easily obtain plaintext data? (Via user-mode injection, ptrace, LD_PRELOAD, eBPF, or kernel-mode kprobes/LKM—intercepting before send/write, after recv/read, or directly hooking crypto library/protocol handshake functions) This attack is even simpler and more reliable than the SS/TLS attacks you mentioned. It requires no MITM, causes no widespread impact beyond a single device, and doesn't render proxies unusable. No user-space proxy software can defend against it.

Similarly, how do you ensure the authentication keys and temporary keys negotiated by Reality aren't exported or reported?

How do you prevent tampering with the Xray binary (where an attacker modifies and compiles a malicious Xray binary to replace the legitimate one, while hooking hash verification functions/system calls to return the correct hash value for the malicious binary)? This would enable code-level manipulation to:

Export plaintext data before outbound transmission? Allow the client to “accept arbitrary server public keys/signatures,” or permanently return verification functions as successful? It (malicious software/backdoor) could also poison the RNG/handshake, hijacking the random number source or replacing curve operations to make the “temporary key” predictable/recalculable. Such attacks cannot be directly detected by a user-mode proxy software.

It (malicious software/backdoor) can also directly hijack proxy configurations set by other software locally, routing traffic through a malicious local proxy before sending it to the local Xray/Reality for inbound processing.

It (malicious software/backdoor) can further tamper with any OS-provided functionality required by your proxy software/protocol, rendering your PIN/built-in CA/binary checks ineffective.

It can also:

Redirect local traffic, copy data before it enters Xray/Reality, then decrypt it using the same configuration

Legitimately decrypt plaintext traffic via local relay before sending it to the server—how would Xray/Reality detect this?

Reuse your subscription channel locally to inject malware, distributing malicious proxy configurations

Last but not least, it can directly dump memory/plaintext data from software on your device (browsers, Telegram, etc.) without needing to attack you at all. It can even read your screen/keyboard/mouse/other I/O devices in real-time and save the data.

...

This is fundamentally beyond the scope of a proxy software/protocol. You should be developing a new host security software project.

You might be furious, but I'm merely pointing out gaps in your foundational knowledge.

As a proxy software/protocol, you're currently delving into operating system security.

Sep 18 '25 11:09 Weltolk

@Weltolk 请不要刷屏，我自己就用 OllyDbg 修改过很多软件，对系统 API hook 的事我也干过，破解软件、做外挂、免杀这些谁不会？假设我不了解这方面的知识是可笑的

关于“恶意系统”的讨论在上面已有很多，区别就是攻击复杂度/是否需要“上报”的问题，我从未认为能够打败“恶意系统”，目标只是提高攻击成本，厂商能开的后门是有限度的，一个恶意木马能做的事情也是有限度的，比如说如果你 hook 了一些敏感的 API，杀软会对此报毒，但如果你只是以“正当名义”安装了一个根证书，比如说游戏加速器/银行相关软件等，该行为会被合理化且你无法拒绝

Please refrain from spamming. I've personally modified numerous software programs using OllyDbg and have experience hooking system APIs. Cracking software, creating hacks, bypassing antivirus detection, who doesn't know how to do these things? It would be ridiculous to assume I lack this knowledge.

Discussions about "malicious systems" have already been extensive above. The distinction lies in attack complexity and whether "reporting" is required. I never believed we could defeat "malicious systems"—the goal is merely to increase attack costs. The backdoors vendors can open are limited, and what a malicious trojan can do is also constrained. For example, if you hook sensitive APIs, antivirus will flag it as a threat. But if you install a root certificate under "legitimate pretense"—like for game accelerators or banking software—the action becomes justified, and you can't refuse it.

Sep 18 '25 12:09 RPRX

@AkinoKaede 对 TLS 证书机制的批评当然不是第一次，但没有一次是像现在这样有切实的证据表明 GFW 实施过此类攻击，TLS 是为了通用的互联网应用而设计出来的，采用公共 CA 机制是难以避免的，然而在反审查领域我们又不是没有别的选择，明明可以通过强制性标准的形式实现等价的 pin 证书为什么还要依赖在该安全实践上操作复杂且难以统一的 TLS？这就是我要表达的意思

Criticism of the TLS certificate mechanism is certainly not unprecedented, but never before has there been concrete evidence like this demonstrating that the GFW has carried out such attacks. TLS was designed for general internet applications, making the use of public CA mechanisms difficult to avoid. Yet in the realm of anti-censorship, we are not without alternatives. Why continue to rely on TLS—a security practice that is operationally complex and difficult to standardize—when we could achieve equivalent pin certificates through mandatory standards? This is precisely my point.

Sep 18 '25 12:09 RPRX

Attempts to distinguish attachs operated by operating systems for user-level apps are certainly fruitless, which beyond what a common app can do. I had thought that a more powerful gov like the USA perhaps implants monitors into our all devices before, but progressing attacks like this requires high permissions and will produce too many data, processing all of them will waste many resources, and governments always put more attention to those who have important positions. For censor circumvention, driving up costs is a practical method.

Sep 18 '25 14:09 MoRanYue

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?

Sep 18 '25 15:09 anon87103946482

@Weltolk 请不要刷屏，我自己就用 OllyDbg 修改过很多软件，对系统 API hook 的事我也干过，破解软件、做外挂、免杀这些谁不会？假设我不了解这方面的知识是可笑的

关于“恶意系统”的讨论在上面已有很多，区别就是攻击复杂度/是否需要“上报”的问题，我从未认为能够打败“恶意系统”，目标只是提高攻击成本，厂商能开的后门是有限度的，一个恶意木马能做的事情也是有限度的，比如说如果你 hook 了一些敏感的 API，杀软会对此报毒，但如果你只是以“正当名义”安装了一个根证书，比如说游戏加速器/银行相关软件等，该行为会被合理化且你无法拒绝

当然, 如果讨论的重点是在设备失陷的前提下, 尽可能的提升攻击者的攻击成本, 而不是完全防范, 我们的方向或许是正确的, 那么

首先, 在这种前提下, 为何"TLS / QUIC 不应被继续视为可靠的加密方式"? 这同样极大的增加了攻击者的成本, 且根证书MITM的攻击方式相对远控更易被发现

其次, 如果你信任现行的主流杀软, 那么前提应该是至少下列条件都达成:

你相信现在主流的杀软不会帮忙作恶
你相信主流的杀软不会被轻易bypass(如果你真如所说的了解免杀等技术, 那么你应该是不会信任任何杀软的, 更何况所谓国家级力量的渗透技术)
或许你知道rootkit/bootkit通常要比杀软所处的层级更低, 杀软通常是无效的
你相信"国家级力量"不拥有某些"合法后门", 这同时也会被av开绿灯, 比如拥有/利用合法的签名驱动(非常常见的被滥用)
你相信操作系统不与某些"国家级力量"勾结, 这会为某些行为直接开绿灯(比如提供os的一些内部api), 甚至直接上报用户隐私数据(这已经被发现) https://mp.weixin.qq.com/s/w7ELHmmF0OPgmu-UQtKQRw
所谓"厂商能开的后门是有限度的", 很显然, 你举的Android上的pdd的例子, 已经反驳了你的观点, 且其是为了盈利并毫无遮掩的进行它们的恶意行为, 如果只是解密和上报流量, 这几乎不会被发现(更何况还需要考虑"中国设备的操作系统协助作恶"与每个设备内置的反诈协助作恶)

利用类似"合法签名驱动"的方式, 与你提到的国家级力量命令并利用第三方软件安装根证书MITM, 是完全类似的攻击方式, 且更常见和隐蔽, 不存在范围性杀伤和代理不可用等情况, 按照你的担忧, 或许前者更应该被重视

最后, 在恶意系统前提下, reality也无法证明自己是可信的. 用"根证书安装更容易"去弱化"设备失陷"的威胁, 不仅没有改变这个结论, 反而再次证明, 区分清楚我们要讨论的是设备的威胁模型, 还是网络的威胁模型, 比争论哪种网络协议更"绝对安全"要重要得多

另外, 我想知道你说的"针对 TLS 的 MITM 等尝试普遍存在"是否还有更多的证据, 我查看了 https://github.com/net4people/bbs/issues/519 与 https://github.com/XTLS/Xray-core/issues/5066 , 我认为这很难证明这种攻击方式已经普遍存在

Sep 18 '25 16:09 Weltolk

Please refrain from spamming. I've personally modified numerous software programs using OllyDbg and have experience hooking system APIs. Cracking software, creating hacks, bypassing antivirus detection, who doesn't know how to do these things? It would be ridiculous to assume I lack this knowledge.

Discussions about "malicious systems" have already been extensive above. The distinction lies in attack complexity and whether "reporting" is required. I never believed we could defeat "malicious systems"—the goal is merely to increase attack costs. The backdoors vendors can open are limited, and what a malicious trojan can do is also constrained. For example, if you hook sensitive APIs, antivirus will flag it as a threat. But if you install a root certificate under "legitimate pretense"—like for game accelerators or banking software—the action becomes justified, and you can't refuse it.

Of course, if the discussion focuses on maximizing the attacker's cost of exploitation after a device compromise—rather than achieving complete prevention—our approach may be correct. In that case:

First, under this premise, why “should TLS/QUIC no longer be considered reliable encryption methods”? This significantly increases the attacker's cost, and root certificate MITM attacks are far easier to detect than remote control attacks.

Second, if you trust mainstream antivirus software, this trust should be predicated on at least the following conditions being met:

You believe current mainstream antivirus solutions won't aid malicious actors
You believe mainstream antivirus won't be easily bypassed (if you truly understand anti-detection techniques as you claim, you likely wouldn't trust any antivirus—let alone so-called “state-level” penetration technologies)
Perhaps you know rootkits/bootkits typically operate at a lower level than antivirus software, rendering it ineffective
You believe “state-sponsored actors” don't possess certain “legitimate backdoors” that antivirus software would also greenlight, such as possessing/exploiting legitimately signed drivers (extremely common abuse).
You believe operating systems don't collude with certain “state-sponsored actors,” which would directly greenlight certain behaviors (like providing access to internal OS APIs) or even directly report user privacy data (this has been discovered): https://mp.weixin.qq.com/s/w7ELHmmF0OPgmu-UQtKQRw
The notion that “The backdoors vendors can open are limited” is clearly refuted by your own example of PDD on Android. Their malicious actions are profit-driven and conducted openly. If it were merely decrypting and reporting traffic, it would likely go undetected (especially considering the complicity of “Chinese equipment and operating systems will assist the target in malicious activities” and "built-in anti-fraud features").

Using methods similar to “legitimate signature drivers” to command and exploit third-party software to install root certificates for MITM attacks is an entirely analogous approach. Such attacks are more common and covert, avoiding issues like widespread disruption or proxy unavailability. Given your concerns, perhaps the former deserves greater attention.

Finally, under a malicious system premise, REALITY cannot prove its own trustworthiness. Using “root certificate installation is easier” to downplay the threat of “device compromise” not only fails to alter this conclusion but further demonstrates that distinguishing whether we're discussing device threat models or network threat models is far more important than debating which network protocol is more “absolutely secure.”

Additionally, I'd like to know if there's further evidence supporting your claim that “attempts like MITM attacks against TLS are widespread.” Having reviewed #519 and XTLS/Xray-core#5066, I find it difficult to conclude that such attacks are already commonplace.

Sep 18 '25 16:09 Weltolk