本帖最后由 yingliu 于 2021-1-28 01:29 编辑
两年前，Mozilla 宣布了对 Firefox Nightly 中保护隐私的扩展 Encrypted Server Name Indication（ESNI）的实验性支持。Server Name Indication（SNI）TLS 扩展通过在 TLS 客户端问候消息中传输服务器主机名的明文副本来启用服务器和证书选择。这表示类似于 DNS 的隐私泄漏，就像 HTTP-over-HTTPS 阻止 DNS 查询将主机名公开给路径上的观察者一样，ESNI 尝试阻止 TLS 握手本身导致的主机名泄漏。
自从 IETF 发布 ESNI 规范草案以来，分析表明仅加密 SNI 扩展会提供不完整的保护。仅举一个例子：在会话恢复期间，预共享密钥扩展可以合法地包含与 ESNI 加密的服务器名称完全相同的明文副本。ESNI 方法所需要的每个扩展中的加密变量，都可能会有隐私安全的隐患，甚至会暴露所公开的扩展集。最后，现实世界中对 ESNI 的使用暴露了交互性和部署方面的挑战，这阻碍了它在更大范围内的启用。
引入 Encrypted Client Hello (ECH)
为了解决 ESNI 的缺点，该规范的最新版本不再仅加密 SNI 扩展，而是加密整个客户端的Hello 消息（因此名称从“ESNI”更改为“ECH”）。现在，任何涉及隐私的扩展都可以降级为加密的“ClientHelloInner”，其本身被标记为未加密的“ClientHelloOuter”的扩展。如果服务器支持 ECH 并成功解密，则将使用“内部” Client Hello 作为 TLS 连接的基础。Cloudflare 在 ECH 上的精彩 博文中对此进行了详细说明。
ECH 还更改了密钥分发和加密过程：支持 ECH 的 TLS 服务器现在通过 HTTPSSVCDNS 记录发布其公钥，而 ESNI 为此使用 TXT 记录。由于 ECH 采用 混合公钥加密规范而不是自定义方案，因此密钥派生和加密变得更加牢固。重要的是，ECH 还添加了重试机制以提高服务器密钥轮换和 DNS 缓存的可靠性。在从DNS 接收过时的密钥之后，ESNI 当前可能会失败的情况下，由于客户端直接从服务器接收更新的密钥，因此 ECH 可以安全地恢复。
ECH 在 Firefox 85 中的运用
为了履行保护在线隐私的使命，Mozilla 与 Cloudflare 以及其他组织积极合作，在 IETF 上标准化了 Encrypted Client Hello 规范。Firefox 85 用 ECH 08 号草案取代了 ESNI，并且即将发布对 09 号草案的更新（旨在进行更广泛的交互性测试和部署）。
之前在 Firefox 中启用 ESNI 的用户可能已经注意到，about:config 中已不再有关于 ESNI 的选项了。虽然已经建议用户等待未来版本中默认启用ECH，但有些用户可能希望更早启用此功能，因此可以在 about:config 中，将 network.dns.echconfig.enabled 和 network.dns.use_https_rr_as_altsvc 设置为 true，这将允许 Firefox 在支持 ECH 的服务器上使用 ECH。在积极开发 ECH 时，其可用性可能是间歇性的，因为它需要客户端和服务器都支持相同的版本。当然，只能在 about:config 下的设置暂时是实验性的，并且随时可能会更改。目前，Firefox ESR 将继续支持以前的 ESNI 功能。
总而言之，ECH 是 ESNI 令人兴奋且强大的进化，并且 Firefox 即将支持该协议。开发团队正在努力确保其交互性和大规模部署的实施，并且渴望用户实现此功能的隐私安全优势。
| 
支持
反对