加密的客户端您好：Firefox中ESNI的未来

两年前，我们宣布了对Firefox Nightly中保护隐私的加密服务器名称指示（ESNI）扩展的实验性支持。服务器名称指示（SNI）TLS扩展通过在TLS客户端问候消息中传输服务器主机名的明文副本来启用服务器和证书选择。这表示类似于DNS的隐私泄漏，就像HTTP-over-HTTPS阻止DNS查询将主机名公开给路径上的观察者一样，ESNI尝试阻止TLS握手本身导致的主机名泄漏。

自从IETF发布ESNI规范草案以来，分析表明仅加密SNI扩展会提供不完整的保护。仅举一个例子：在会话恢复期间，预共享密钥扩展可以合法地包含与ESNI加密的服务器名称完全相同的明文副本。 ESNI方法将需要每个扩展的加密变体，这可能会隐含隐私，甚至会暴露所宣传的扩展集。最后，现实世界中对ESNI的使用暴露了互操作性和部署方面的挑战，这阻碍了它在更大范围内的启用。

为了解决ESNI的缺点，该规范的最新版本不再仅加密SNI扩展，而是加密整个Client Hello消息（因此名称从“ ESNI”更改为“ ECH”）。现在，任何涉及隐私的扩展都可以降级为加密的“ ClientHelloInner”，其本身被广告为未加密的“ ClientHelloOuter”的扩展。如果服务器支持ECH并成功解密，则将使用“内部”客户端Hello作为TLS连接的基础。 Cloudflare在ECH上的精彩博客文章中对此进行了详细说明。

ECH还更改了密钥分发和加密过程：支持ECH的TLS服务器现在通过HTTPSSVC DNS记录发布其公钥，而ESNI为此使用TXT记录。由于ECH采用混合公钥加密规范而不是定义自己的方案，因此密钥派生和加密变得更加健壮。重要的是，ECH还添加了重试机制以提高服务器密钥轮换和DNS缓存的可靠性。在从DNS接收过时的密钥之后，ESNI当前可能会失败的情况下，由于客户端直接从服务器接收更新的密钥，因此ECH可以安全地恢复。

为了履行保护在线隐私的使命，Mozilla与Cloudflare以及其他组织积极合作，在IETF上标准化了加密客户端Hello规范。 Firefox 85用ECH草稿08取代了ESNI，并且即将发布对草稿09的另一个更新（旨在进行更广泛的互操作性测试和部署）。

先前在Firefox中启用ESNI的用户可能会注意到，不再存在ESNI的about：config选项。尽管我们建议用户等待默认情况下启用ECH，但有些用户可能希望更早启用此功能。可以通过将network.dns.echconfig.enabled和network.dns.use_https_rr_as_altsvc设置为true来在about：config中完成，这将允许Firefox在支持ECH的服务器上使用ECH。在积极开发ECH时，其可用性可能是间歇性的，因为它需要客户端和服务器都支持相同的版本。与往常一样，仅在about：config下公开的设置被认为是实验性的，并且可能会更改。目前，Firefox ESR将继续支持以前的ESNI功能。

总而言之，ECH是ESNI令人兴奋且强大的演进，并且Firefox即将支持该协议。我们正在努力确保其可互操作性和可大规模部署，并且我们渴望用户实现此功能的隐私优势。