Mozilla 在 Firefox Nightly 版本中开始实验测试 ESNI 功能

1月9日消息   两年前为了更好地保护用户隐私，Mozilla 在 Firefox Nightly 版本中开始 实验测试 ESNI 功能。不过由于 ESNI 存在诸多安全隐患，Mozilla 近日宣布自 Firefox 85 版本开始将会迁移到 Encrypted Client Hello (ECH)上。

ESNI 全称是加密服务器名称指示(Encrypted Server Name Indication)，是 TLS 的一些扩充协议，主要是为了解决主机名称泄漏的问题。该协议在通信过程开始的时候，由客户端在 TLS Client Hello 讯息中，以明文传送要连接的服务器主机名称，以连接到特定服务器，并选择使用的凭证。

▲ TLS 1.3 握手过程

▲ 带 ESNI 的 TLS 1.3 握手过程

▲ 使用 ECH 的 TLS 1.3 握手过程

自从 ESNI 规范草案在 IETF 上发布以来，分析表明仅仅加密 SNI 扩展提供的保护是不完整的。举个例子：在会话恢复过程中，Pre-Shared Key 扩展可以合法地包含一个与 ESNI 加密的服务器名称完全相同的明文副本。

而伴随着越来越多的网站普及 HTTPS，依然采用明文的 SNI 成为新的隐私漏洞。通过明文 SNI，ISP 或任何网络中间人将会知道你访问了哪个网站。ESNI 方法将需要每个扩展的加密变体，具有潜在的隐私影响，即使这样也会暴露广告中的扩展集。

为了解决 ESNI 的问题，最近发布的规范不再只加密 SNI 扩展，而是对整个 Client Hello 信息进行加密，因此名称从 ESNI 改成 ECH。任何涉及隐私的扩展现在都可以归入一个加密的 "ClientHelloInner"，而这个 "ClientHelloInner "本身就被宣传为未加密的 "ClientHelloOuter "的扩展。如果服务器支持ECH并成功解密，"内层"Client Hello就会被用作TLS连接的基础。

ECH还改变了密钥分配和加密故事。支持ECH的TLS服务器现在通过HTTPSSVC DNS 记录来宣传其公钥，而 ESNI则使用TXT记录来实现这一目的。由于ECH采用了混合式公钥加密规范，而不是定义自己的方案，因此密钥推导和加密变得更加强大。

重要的是，ECH 还增加了重试机制，以提高服务器密钥轮换和DNS缓存的可靠性。目前，ESNI在从DNS接收到陈旧的密钥后可能会失败，ECH可以安全地恢复，因为客户端直接从服务器接收更新的密钥。

为了更好的保护用户隐私，Mozilla 宣布正与 Cloudflare 和其他公司积极合作，在 IETF 上对加密 Client Hello 规范进行标准化。Firefox 85 用 ECH draft-08 取代了 ESNI，并且即将对 draft-09 进行另一次更新(目标是进行更广泛的互操作性测试和部署)。

之前在 Firefox 中启用过 ESNI 的用户可能会注意到，ESNI 的 about:config 选项已经不存在了。虽然 Mozilla 建议用户等待 ECH 被默认启用，但有些用户可能会希望提前启用该功能。用户可以在 about:config 中通过将 network.dns.echconfig.enabled 和 network.dns.use_https_rr_as_altsvc 设置为 true 来实现，这将允许 Firefox 在支持ECH的服务器上使用ECH。

去年 12 月，就有用户反馈 Firefox Nightly 不再支持 ESNI