互动为何 RFC 9849 会引发“审查与封锁”

RFC 9849 是互联网工程任务组（IETF）于 2026年3月 正式发布的互联网标准（Standards Track），其核心内容是定义了 ECH（Encrypted Client Hello，加密客户端问候） 技术。 [1, 2, 3, 4]
该标准在“网络审查”与“反封锁”的博弈中处于极其关键的地位。



一、 核心攻防：为何 RFC 9849 会引发“审查与封锁”

在传统的 HTTPS（TLS 1.3 及更早版本）连接中，虽然通信内容是加密的，但客户端在握手初期必须以明文发送 SNI（服务器名称指示），以便服务器知道该出示哪个网站的证书。 [1, 2]

- 审查方的传统手段： 防火墙（如 DPI 深度包检测设备）通过拦截和读取明文 SNI，就能精准获知用户正在访问哪个域名，并直接实施精准阻断（如发送 TCP Reset 报文或丢包）。 [1, 2]
- RFC 9849 的技术反击： ECH 将整个 ClientHello（包括 SNI）放入了一个加密信封中（ClientHelloInner），而暴露在外的只有一条指向托管服务商（如 Cloudflare 等 CDN）的公用伪装域名（OuterSNI/public_name）。这使得外部审查设备只能看到用户连接到了某个大型云服务商，却无法知道具体访问的是哪一个敏感网站。 [1, 2, 3, 4, 5, 6]




二、 审查方的封锁与应对策略

由于 RFC 9849 (ECH) 抹去了网络审查最依赖的“域名指标”，多国及企业级防火墙为了维持审查能力，采取了以下激进的封锁与对抗手段：

- 直接阻断包含 ECH 扩展的握手包
部分国家的防火墙设备（例如俄罗斯的 TSPU 系统在 ECH 草案和标准发布期间）采取了“一刀切”策略。一旦检测到 TLS 握手报文中包含 ECH 扩展字段，或者外层域名匹配到了特定的公共服务（如 cloudflare-ech.com），直接对该连接进行断网或丢包阻断。 [1, 2]

- 封锁加密 DNS（DoH / DoT）
ECH 的工作高度依赖于客户端提前通过 DNS 获取服务器的加密公钥（通过 HTTPS/SVCB 记录）。如果 DNS 查询本身是明文的，审查方依然能从 DNS 请求中获取目标域名。因此，审查方（如中国、伊朗等地的网络防火墙）会集中力量封锁和干扰常规的公网 DoH/DoT 服务，通过切断 ECH 的“密钥分发渠道”来使其降级失效。 [1, 2, 3]

- 强制降级攻击（Downgrade Attacks）
如果防火墙干扰或剥离了 DNS 中的 ECH 记录（通过 DNS 污染或篡改），客户端由于拿不到有效的公钥，会迫不得已退回到没有 ECH 的普通 TLS 握手，从而再次暴露明文 SNI，允许防火墙继续审查。 [1]

- 企业级环境中的“中间人”（MITM）解密
在企业内网中，网络管理员为了防止员工通过 ECH 规避合规性审查（如上网行为管理、防勒索病毒），通常会在内网终端强制安装企业根证书，并通过下一代防火墙（NGFW）对所有 TLS 流量进行中间人代理（MITM）解密，从而在网关处剥离 ECH 的隐私保护。 [1]




三、 RFC 9849 的局限性

尽管 RFC 9849 极大提升了隐私性，但在技术上它并不能彻底终结网络封锁： [1]

- 无法隐藏 IP 地址： 如果被封锁的网站使用独立的、专用的固定 IP 地址，审查方无需看域名，直接针对该 IP 进行封锁，ECH 将完全失去作用。它只有在网站寄宿于大型 CDN（数万家网站共享同一组 IP）时，才能发挥“投鼠忌器”的反封锁效果。 [1, 2]
- 依赖生态普及： ECH 需要浏览器（客户端）和 Web 服务器（如 Nginx 1.29+、OpenSSL 4.0+、Cloudflare）双向支持。在生态未完全普及前，开启 ECH 的流量由于特征过于明显，反而容易成为防火墙重点致盲和干扰的目标。 [1, 2, 3]