ECH （加密 ClientHello（Encrypted Client Hello））

ECH 已于 2026 年 3 月发布为 RFC 9849。客户端会构造两个 ClientHello：内层包含真实的 SNI、ALPN 列表等私密扩展，用 HPKE 以服务器的 ECH 公钥加密；外层只携带前端服务器的公共名称。前端服务器解密内层 ClientHello 后，用它继续完成握手。

为什么重要

即便在 TLS 1.3 中，SNI 也是明文，链路上任何设备都能看到客户端要访问的域名。ECH 补上了这一点：当大量站点共用同一个前端时，外部只能看到共享的公共名称。ECH 配置通常放在 DNS HTTPS 记录的 ech 参数里，浏览器一般通过加密 DNS 获取，因为明文 DNS 查询本身就会暴露域名。规范还设计了重试机制：服务器解不开内层时，会用外层完成握手并下发新的配置，客户端再重连，避免 DNS 缓存过期导致连接一直失败。对企业网络来说，ECH 意味着按 SNI 识别流量的安全策略将看不到真实域名，部署安全网关时需要提前评估。

例子

dig +short HTTPS example.com
# 1 . alpn="h3,h2" ech=<base64 编码的 ECHConfigList>

存在这样的记录且浏览器支持 ECH 时，抓包看到的外层 ClientHello 里只有服务商的公共名称。

常见误区

• 开了 ECH，访问记录就完全隐身了。 目标 IP、未加密的 DNS 查询和流量特征仍可能暴露信息，ECH 主要在多个站点共用前端时才能有效隐藏域名。
• ECH 就是改了名的 ESNI。 ESNI 只加密 SNI 扩展，且从未成为 RFC；ECH 加密的是整个内层 ClientHello。
• 服务器改一个配置就能开 ECH。 它需要 TLS 1.3、ECH 密钥对、DNS 发布和密钥轮换，目前主要由 CDN 和大型服务商部署。