摘要

  • ECH 把真实 SNI 等敏感参数放入加密的 ClientHelloInner，再由可公开观察的 ClientHelloOuter 携带。
  • 隐私不是一次加密调用的产物：DNS 必须送达当前配置，前端必须持有正确密钥，后端必须确认内层握手，失败也必须以可识别的方式重试。
  • ECH 不会自动隐藏 DNS 查询、目标 IP 或所有流量侧信号；区域里出现 ech 参数，只代表发布了指令，不代表连接已经受保护。

缓存里的一把旧钥匙

想象密钥刚刚轮换，权威区已经发布新值，但一台客户端仍持有 TTL 内的旧配置。它发出的内层问候并没有加密错误；公共前端只是已经不再认识那把钥匙。ECH 的工程难点，正是在这种时间差里显现。

RFC 6066 定义 server_name 扩展，让共用基础设施上的多个虚拟服务知道客户端要找谁。RFC 8446 规定 ClientHello 是 TLS 1.3 的第一条消息。于是，真正站名在后续握手受到加密保护以前就已经暴露。

2026 年 3 月发布的 IETF 标准轨 RFC 9849 把一份问候拆成内外两层。内层含真实 SNI、ALPN 等敏感选择；客户端依据 ECHConfig 中的公钥，以 HPKE 加密它。外层只带公共值，并在 encrypted_client_hello 扩展里装入密文。

前端若接受 ECH，就处理或转交内层；若无法打开，就按外层继续，并可返回新的重试配置。客户端要判断是否接受。已经承诺使用 ECH 却被拒绝的连接不能直接承载应用数据；拒绝通向重试，而不是伪装成成功的降级。

公共前门承担了新的分工

共享模式下，公共前端本身就是 TLS 终结点。分离模式下，前端只打开内层问候，再把它交给独立后端终结 TLS。前端因此知道分流所需的目标，但不必终结受保护的应用流。

这不是无关紧要的拓扑差异。DNS 发布者决定配置；客户端决定是否提供；前端掌握私钥和仍可能出现在缓存中的旧配置；后端把接受结果绑定到正确握手记录。四者中任何一处只看自己的“绿色状态”，都无法证明整条链路。

轮换频率也没有单一答案。快换能缩短密钥泄露后的暴露窗口，却会增加旧缓存和重试；保留过多旧钥匙又会提高试探解密的成本。RFC 给出处理规则，不替运营者选择普遍适用的周期。

DNS 在 TLS 之前递交隐私指令

RFC 9848 为 RFC 9460 的 SVCB 与 HTTPS 记录定义 ech 服务参数。客户端在连接前，由此获得候选端点及其 ECH 配置。

这也形成新的降级面。若同一 RRSet 同时包含有 ECH 和无 ECH 的端点，中间者可封锁受保护端点，只留下明文选择；RFC 9848 不建议这种混合。若 SVCB 解析被整体阻断，客户端甚至不知道服务原本要求 ECH。

加密 DNS 传输能挡住接入网里的旁观者，却不会让递归解析器不知道查询名。公共前端的 IP 也仍可观察。ECH 精确保护的是 TLS 问候里的站名，不是让整条网络路径隐形。

匿名集合必须真的像一个集合

ECH 的目标依赖多个站名共用配置并表现出相近的公共行为。若每个站名都有独立配置标识，集合可能退化为一个成员。即使密钥相同，独特的密码套件、扩展顺序、记录边界或重试 cookie 也可能留下轮廓。

内层加密完全正确，不等于外层不可区分。因此审计不能只看一个域名能否握手，还要比较同组成员的公共问候是否一致。

GREASE 让失败不再只有一种解释

GREASE ECH 会在没有可用真实配置时发送形似 ECH 的扩展，用来暴露不兼容中间盒，也避免真实 ECH 成为唯一突出的形状。因此一次解密失败不能直接定性为配置损坏。重试配置是否一致、是否形成循环，以及 ech_required 告警，才是更具体的运营证据。

事实包没有回答的问题

五份 RFC 证明格式、角色、重试和威胁模型，不证明某个浏览器、解析器或接入网在 2026 年 8 月的实际状态，也不证明某家提供商的匿名集合有多大。这些结论必须另行测量。

来源