ECH:TLS 怎样把连接时暴露的网站域名也藏起来?

TL;DR

ECH 将 TLS 握手中的目标站点信息放入加密的 ClientHello,降低旁路观察者直接看到域名的机会。本文介绍 inner/outer ClientHello 的角色,并说明 IP 地址与其他元数据仍可能暴露。

ECH 将 TLS 握手中的目标站点信息放入加密的 ClientHello,降低旁路观察者直接看到域名的机会。本文介绍 inner/outer ClientHello 的角色,并说明 IP 地址与其他元数据仍可能暴露。

ECH:TLS 怎样把连接时暴露的网站域名也藏起来?

访问 HTTPS 网站时,网页正文会加密,但在 TLS 握手早期,客户端通常需要告诉服务器自己要访问哪个站点。传统 TLS 的 ClientHello 中,服务器名称指示(SNI)可能以明文出现,使链路上的观察者看见域名。ECH(Encrypted Client Hello,加密客户端问候)试图把这部分早期元数据也纳入加密保护。

要理解 ECH,先看 TLS 握手。客户端在建立加密会话前发送 ClientHello,里面包含协商加密参数等信息,服务器据此选择配置。为了让共享 IP 上的服务器知道应使用哪个站点配置,传统握手会携带目标主机名。ECH 采用加密的 inner ClientHello,并由外层 ClientHello 承载有限的公开信息;真正的目标站点名称放入加密部分,只有持有对应密钥的服务器端才能解开。

这并不是把整个网络连接都隐形。观察者仍可能看到用户连接到哪个 IP 地址、连接发生的时间与流量大小;解析器和网络运营方也可能从 DNS 或其他信号推断访问意图。ECH 的隐私效果还受到部署方式影响:若只有少数站点启用,外层信息可能让目标范围变得明显;若多个站点共用相同入口,混淆集合更大,才更难从外部区分具体目标。

ECH 也需要客户端、DNS 配置与服务器端协同。客户端要获得服务器的 ECH 配置,服务器或前端基础设施要持有相应私钥并正确处理握手。网络设备、内容分发网络和网站部署方式都可能影响兼容性。某些失败场景下,客户端还需要遵循协议定义的回退处理,确保连接可靠建立。

可以把它想成把目的地写进一个只有前台能打开的内层信封,再把信封交给共享前台。路上看到外层信封的人知道你去了这栋楼,却不一定知道你要找哪位住户。若这栋楼只有一家住户,隐私就弱一些;若许多站点共用同一入口,目标更难被区分。

因此,ECH 不是 VPN,也不是隐藏 IP 地址的匿名工具。它针对的是 TLS 握手中可能暴露的站点名称,降低被动观察者获知具体域名的机会。用户是否能获得保护,取决于浏览器、解析服务、站点/CDN 的实际支持和部署。它是隐私拼图里一块重要的补充,而非一键匿名。

来源:IETF RFC 9849:TLS Encrypted Client Hello

KEEP READING