题干与适用场景
你负责一个由 CDN 承载的多域名服务。安全团队发现即使启用 TLS，网络观察者仍能从 ClientHello 中看到明文 SNI，并希望评估 Encrypted Client Hello（ECH）。请说明客户端如何获取 ECH 配置、外层和内层 ClientHello 的职责、CDN 到源站的边界、兼容旧客户端的回退以及上线后的诊断指标。
面试官考察点
面试官要确认你理解 ECH 是 TLS 扩展，不是 VPN、DNS 加密或完整流量隐身。客户端用服务端发布的公钥加密 inner ClientHello，再用 outer ClientHello 与 client-facing server 建立连接；外层只暴露用于路由的公共名称。高质量回答还会指出 ECH 依赖 HTTPS/SVCB 记录或其他配置分发、需要 CDN 和客户端支持，并且不能隐藏 IP、流量大小、时间和连接目的地等侧信道。
回答前需要澄清的问题
观察者和隐私目标
确认要防护的是被动网络观察者、企业代理还是恶意中间人，以及是否仍允许网关基于策略域名进行审计。不同观察者看到的 IP、DNS、外层名称和连接时序不同。
服务拓扑和密钥边界
确认 ECH 在 CDN 边缘终止还是由自建入口终止，源站是否还需独立 TLS。ECH 私钥的轮换、分发和撤销责任必须属于明确的边界，不能把 CDN 公钥当作源站证书。
兼容与回退政策
确认目标浏览器、操作系统、DoH/DoT、HTTP/3 和企业中间盒支持情况。回退到未加密 SNI 会恢复兼容性，也会恢复观察风险，应由策略和指标共同决定。
30 秒回答框架
“ECH 让客户端用服务端发布的 ECH 公钥加密 inner ClientHello，把真实 SNI 等敏感字段放进内层；outer ClientHello 只带公共名称，让 client-facing server 完成路由。配置通常通过 HTTPS/SVCB 等机制获得，边缘节点解密内层后继续普通 TLS 1.3。ECH 失败时可按策略回退或中止，不能把回退当成同等隐私。它仍不隐藏 IP、流量大小、时间和 DNS 解析等元数据，所以要把 ECH 与 DNS、CDN、监控和密钥轮换一起评估。”
分步骤深入解答
第一步：发布 ECH 配置
服务端发布包含公钥、版本和封装元数据的 ECHConfig。客户端通过受信的 DNS HTTPS/SVCB 记录或浏览器配置获得它，并校验记录来源。配置需要版本化和过期策略，旧配置不能无限期留在缓存中。
第二步：构造外层和内层握手
客户端把真实的 SNI、ALPN 和其他敏感扩展放进 inner ClientHello，用 ECH 公钥加密；outer ClientHello 只携带可公开的名称和加密载荷。outer 名称通常指向能够解密 ECH 的 client-facing server，而不是直接暴露最终服务域名。
第三步：边缘节点处理
边缘收到 outer ClientHello 后，使用 ECH 私钥尝试解密 inner。成功时按内层参数选择证书和路由；失败时按 TLS 规范发送 retry 配置或终止连接。边缘到源站的 TLS 仍是独立安全边界，ECH 不会替代源站认证。
第四步：处理回退与攻击面
客户端可能因为配置过期、版本不兼容、DNS 被篡改或中间盒阻断而无法使用 ECH。服务端可发布 retry 配置，客户端重新获取后再试；若允许明文 SNI 回退，应限制场景并记录原因。不能把任意 retry 配置直接信任为成功，防止降级和错误路由。
第五步：说明隐藏与未隐藏的信息
ECH主要隐藏 ClientHello 内的站点名称和相关扩展。观察者仍可能看到 DNS 查询、外层名称、目标 IP、握手时间、连接次数、包长和后续流量模式。若 DNS、CDN 和应用部署泄露唯一外层名称，匿名集合也会变小。
第六步：密钥和运维治理
为 ECH 私钥设定轮换、双人审批、回滚和紧急撤销流程。监控配置发布时间、客户端接受率、retry 率、解密失败、TLS 告警、不同 CDN 节点的版本差异，并保留不含真实 SNI 的诊断标识。日志不能为了排查而记录 inner ClientHello 的敏感字段。
第七步：渐进发布和验证
先在受控域名和支持的客户端灰度，比较 ECH 开启、回退和中止的成功率、握手时延、HTTP/2/3 协商与源站错误。用受控的过期配置、错误私钥、中间盒和多节点轮换测试失败路径，再验证旧客户端仍可按策略访问。
高质量示范回答
ECH 是 TLS 1.3 的扩展，用服务端发布的 ECHConfig 公钥加密 inner ClientHello。真实 SNI、ALPN 等字段放在内层，outer ClientHello 只带公共名称和加密载荷；支持 ECH 的 CDN 边缘用私钥解密内层，再按普通 TLS 选择证书和路由。边缘到源站仍需独立 TLS，ECH 不取代源站认证。
我会先确认威胁模型、DNS/SVCB 配置分发、CDN 私钥边界和回退政策。配置过期、版本不兼容或中间盒阻断时，可以使用受信的 retry 配置重试；只有明确允许时才回退到明文 SNI，并把原因计入指标。ECH 隐藏的是握手字段，不是 IP、DNS、流量大小和时序。上线观察接受率、retry、解密失败、握手时延和源站错误，轮换密钥时用版本化配置和可回滚流程。
常见错误
- 错误表现： 认为启用 ECH 就等于所有访问都匿名。→ 失败原因： IP、DNS、连接时序和流量大小仍可能暴露关联。→ 修正方法： 明确匿名集合和剩余侧信道，协同评估 DNS 与 CDN。
- 错误表现： 把 ECH 私钥和源站证书当成同一把密钥。→ 失败原因： 边缘解密与源站认证是两个安全边界。→ 修正方法： 分离密钥生命周期、权限和轮换流程。
- 错误表现： ECH 失败后无条件回退。→ 失败原因： 攻击者可以制造失败诱导降级，隐私策略失效。→ 修正方法： 对 retry、终止和回退分别设定策略与告警。
- 错误表现： 为了排障记录完整 inner ClientHello。→ 失败原因： 日志重新暴露了本想隐藏的站点信息。→ 修正方法： 记录配置版本、节点和错误类别，不记录敏感字段。
追问及应对
追问一：ECH 与 ESNI 有什么关系？
ESNI 主要只保护 SNI；ECH 把更完整的 ClientHello 放进加密的 inner 结构，并定义 outer/inner 协作和配置分发。面试中应以当前 ECH 标准和部署文档为准，不能把旧 ESNI 术语当作完整实现。
追问二：中间盒看不到真实域名后，企业如何做合规审计？
先确认企业是否控制终端和出口网关。受管设备可以在终端或受信代理保留策略所需的审计信号；公共网络不能因为看不到 SNI 就声称 ECH 破坏了 TLS。隐私目标和组织可见性要通过明确的政策边界协调。
追问三：为什么 outer 名称会影响隐私？
如果一个 outer 名称只服务一个真实站点，观察者仍可通过 IP、DNS 和名称把连接缩小到该站点。共享入口和足够大的匿名集合能改善隐私，但会增加路由、证书和运维复杂度。
追问四：如何判断是 ECH 失败还是普通 TLS 失败？
结合客户端是否携带 ECH、配置版本、边缘 retry、解密失败计数、TLS alert、节点和时间窗口对照。对同一客户端重复测试 ECH 开启、关闭和旧配置，避免把证书、ALPN 或源站健康问题误归因于 ECH。