题干与适用场景
TLS 1.3 加密了大部分握手内容，但传统 ClientHello 可能暴露 SNI，使网络观察者推断目标服务。请说明 ECH 的协议角色、密钥配置分发和失败行为，并区分“隐藏 SNI”与“隐藏所有流量特征”。
题目适合网络、安全、平台和通用协议岗位。核心考察 TLS 握手与隐私边界，因此归为 general。
面试官考察点
第一，是否理解外层和内层 ClientHello。ClientHelloOuter 提供兼容外观，真正目标信息放在由服务端配置公钥加密的 ClientHelloInner。
第二，是否理解配置分发。客户端需要 ECHConfig，其中包含公钥和算法元数据；配置可通过 DNS SVCB/HTTPS 记录等方式获得，但分发本身要考虑真实性与新鲜度。
第三，是否知道 ECH 不是端到端匿名。DNS、IP、流量时序、证书和未启用 ECH 的路径仍可能泄露信息。
第四，是否能解释失败回退。ECH 不可用时客户端可能发送普通 ClientHello 或重试，策略必须避免把错误配置当作成功隐私保护。
第五，是否能设计可观测验证。应检查握手扩展、客户端与边缘日志、配置命中率和回退率，而不是只看 HTTPS 成功。
回答前需要澄清的问题
- 客户端、边缘代理、TLS 库是否支持 RFC 9849？
- ECHConfig 通过哪个 DNS 记录或配置渠道分发，DNSSEC/加密 DNS 如何处理？
- 服务是否有共享前端和多个后端名称？
- 失败时允许明文 SNI 回退，还是必须硬失败？
- 需要保护的是域名、租户名称还是更广泛的流量元数据？
- 观测系统能否记录 ECH 成功而不泄露内层名称？
30 秒回答框架
“ECH 把真实目标放进 ClientHelloInner，并用服务端发布的 ECHConfig 公钥进行 HPKE 加密；ClientHelloOuter 维持握手兼容性。配置可经 DNS SVCB/HTTPS 分发，但要验证来源和新鲜度。ECH 失败时按策略回退或硬失败，不能把 TLS 成功当作隐私成功。验证要结合握手扩展、边缘指标、配置命中率与回退率，同时承认 DNS、IP 和流量模式仍可泄露。”
分步骤深入解答
第一步：区分两个 ClientHello
客户端构造 ClientHelloInner，放入真实 SNI 和其他希望隐藏的扩展；再生成 ClientHelloOuter 作为外层兼容消息。服务端或边缘端使用 ECHConfig 中的公钥解密内层，无法解密时按协议处理失败。
第二步：理解 HPKE 与配置
ECHConfig 包含版本、公共密钥、密码套件和服务端元数据。客户端使用 HPKE 保护 ClientHelloInner，服务端持有对应私钥。配置轮换需要重叠有效期、缓存控制和密钥撤销策略，不能把公钥写死在客户端。
config = fetch_ech_config()
inner = build_client_hello(real_sni, extensions)
outer = build_outer_hello(public_name, ech_extension)
encrypted_inner = hpke_seal(config.public_key, inner)
send(outer, encrypted_inner)第三步：讨论 DNS 分发和真实性
ECHConfig 可以通过 SVCB/HTTPS 记录等机制发现。DNS 记录需要新鲜度、缓存和篡改风险评估；加密 DNS 只能保护传输路径的一部分，DNSSEC 与应用策略仍决定客户端是否信任配置。错误或过期配置应触发重新获取。
第四步：定义失败与回退
服务端无法解密、配置过期、GREASE 或扩展不兼容时，客户端可能重试或回退普通握手。产品策略应明确哪些域名允许回退，哪些隐私要求必须硬失败，并记录原因。回退不是 ECH 成功，不能静默计入成功率。
第五步：识别仍然暴露的信息
ECH 隐藏 ClientHello 中的目标名称，但 DNS 查询、目标 IP、连接时间、包大小、证书和后续应用行为仍可能用于流量分析。安全目标应写成减少特定握手元数据暴露，而非宣称匿名。
第六步：设计部署与密钥轮换
边缘集群部署私钥时使用最小权限和审计，配置发布要支持旧新密钥重叠。多区域缓存需要一致的版本和失效策略；密钥泄露时应撤销配置、缩短 TTL 并观察回退率。
第七步：建立端到端验收
使用支持和不支持 ECH 的客户端、不同 DNS 解析路径和多个边缘节点测试。记录 ECH extension 是否协商、配置版本、解密失败、回退率、握手延迟和连接错误。抓包验证时注意不要把内层敏感名称写入日志。
高质量示范回答
“ECH 不是另一个应用层加密，而是 TLS 握手扩展。客户端把真实 SNI 放进 ClientHelloInner，用 ECHConfig 公钥通过 HPKE 加密，再用 ClientHelloOuter 保持兼容。ECHConfig 可经 SVCB/HTTPS 记录发现，需处理 DNS 真实性、缓存和轮换。
部署时我会明确失败策略：隐私要求高的入口硬失败，允许兼容的入口记录并区分普通握手回退。观测包括协商扩展、配置命中、解密失败、回退率和握手延迟；同时说明 DNS、IP、证书和流量特征仍可能暴露信息。验收覆盖多客户端、DNS 路径和密钥轮换。”
常见错误
- 说 ECH 隐藏所有流量 → DNS、IP 和时序仍可见 → 限定隐私目标。
- 把 ECHConfig 公钥写死 → 轮换和撤销困难 → 使用可更新配置。
- 只看 HTTPS 成功 → 普通握手回退被误算为 ECH 成功 → 记录扩展与回退原因。
- 忽略 DNS 篡改和陈旧缓存 → 客户端使用错误配置 → 评估真实性、TTL 和刷新。
- 把 Outer SNI 当真实目标 → 误解兼容外观 → 区分 public name 与 inner SNI。
- 密钥轮换无重叠 → 多区域客户端间歇失败 → 设计重叠窗口和失效策略。
- 日志记录内层名称 → 观测系统重新泄露隐私 → 只记录哈希、版本和状态。
- 忽略不支持客户端 → 真实用户路径无法连接 → 保留明确回退或硬失败规则。
追问及应对
追问一：ECH 与 DoH/DoT 是什么关系？
ECH 保护 TLS ClientHello，DoH/DoT 保护 DNS 传输；两者解决不同阶段的问题，可以组合但互不替代。
追问二：为什么需要 ClientHelloOuter？
它提供兼容外观，让不理解 ECH 的中间设备仍能处理握手，同时把真实目标放到加密的内层。
追问三：ECH 失败时一定要回退吗？
不是。策略取决于隐私与可用性要求；高隐私入口可硬失败，兼容入口可回退但必须可观测、可计数。
追问四：如何验证中间盒没有破坏 ECH？
从客户端、边缘和服务端分别记录协商状态，在不同代理链路抓取元数据并比较成功率、回退率和握手错误。
追问五：密钥泄露后怎么办？
撤销或停止发布旧 ECHConfig，缩短缓存 TTL，部署新密钥，并监控解密失败与回退。历史已暴露的 ClientHello 无法事后恢复隐私。
追问六：ECH 是否隐藏证书中的域名？
它主要隐藏握手中的目标名称；证书、DNS、IP 和应用层信息仍可能提供关联线索，不能承诺完全隐藏域名。