ECH

ECH（RFC 9849）把 TLS ClientHello 中的 SNI 等字段加密，防止旁观者从 SNI 推断访问了哪个站点；ECH 配置通过 HTTPS/SVCB 记录（RFC 9848）经 DNS 分发。

#type / concept #status / growing #tech / network #protocol / dns

[!info] related notes

所属 MOC: DNS 知识地图

配置载体: HTTPS / SVCB 记录

加密 DNS: DoH / DoT

排障: tls-handshake-failure-debugging / dns-wrong-ip-tls-handshake-failure-debug

ECH

一句话定义

ECH（Encrypted Client Hello, RFC 9849） 加密 TLS 握手中的 ClientHello 关键字段（尤其是 SNI），让链路旁观者无法再从 SNI 推断你访问了哪个站点。ECH 配置需在建立 TLS 前获得，由 HTTPS/SVCB 记录（RFC 9848） 经 DNS 分发。

核心机制 / 工作原理

过去即使网站用 TLS 1.3，ClientHello 里的 SNI 通常仍是明文：

ClientHello 明文携带: anyrouter.top   ← 旁观者可见

ECH 把这部分用服务端公钥（从 DNS 拿到的 ech 配置）加密：

ClientHello 外层: 不可读的密文（含加密的 SNI）

现代链路逐渐变成：

加密 DNS（拿到 HTTPS RR + ECHConfig）
   ↓
用 ECH 加密 ClientHello
   ↓
建立 HTTPS/HTTP3 连接

最小例子 / 最小场景

dig anyrouter.top HTTPS      # 若带 ech=...，支持 ECH 的浏览器会尝试加密 SNI
openssl s_client -connect anyrouter.top:443 -servername anyrouter.top

若服务端支持且客户端拿到 ECH 配置，SNI 不再明文暴露。

边界与易混淆点

协议已标准化 ≠ 全面部署：网站、浏览器、DNS 服务、网络任一环不支持，ECH 就不会启用。
ECH 依赖 DNS 先给配置：若本地解析路径拿不到正确的 HTTPS 记录（被过滤或走错解析器），ECH 无法启用（见 dns-https-svcb-records、dns-filtering-hijacking-pollution）。
ECH 加密 SNI，但不隐藏「你连了哪个 IP」——目标 IP 仍可见；要同时隐藏目标需配合代理/隧道（见 proxy-and-dns-separation）。
ECH 失败可能导致握手异常；排障时要区分「没启用 ECH」与「握手真的失败」（见 tls-handshake-failure-debugging）。
与 DoH/DoT 互补：DoH 加密 DNS 查询内容，ECH 加密 TLS 中的 SNI，二者共同减少元数据泄露。