几周前，我们宣布支持加密服务器名称指示（SNI）TLS扩展（简称ESNI）。正如我们承诺的那样，我们在Mozilla的朋友每晚都会在Firefox中获得对ESNI的支持，因此您现在可以浏览Cloudflare网站，而不会将明文SNI TLS扩展泄露给在线观察者（isp、咖啡店老板、防火墙等）。今天我们将向您展示如何启用它，以及如何在我们的浏览体验安全检查中获得满分。夜幕降临了第一步是下载并安装最新的Firefox Nightly版本，或者，如果您已经安装了Nightly，请确保它是最新的。当我们宣布支持ESNI时，我们还创建了一个测试页面，您可以将其指向您的浏览器https://encryptedsni.com检查您的浏览器/DNS配置在连接到我们的测试页面时是否通过使用安全DNS传输、DNSSEC验证、TLS 1.3和ESNI本身来提供更安全的浏览体验。在您对Firefox配置进行任何更改之前，您可能会看到如下结果：所以，还有改进的余地！下一步，前往关于：配置页寻找网络安全.esni.enabled选项（您可以在顶部的搜索框中键入名称以筛选出不相关的选项），并通过双击其值将其切换为true。现在，加密SNI已启用，当您访问支持它的网站（包括Cloudflare上的所有网站）时，将自动使用加密SNI。需要注意的是，正如我们的博客文章中所解释的，您还必须启用对HTTPS上的DNS的支持（在Firefox中也称为"可信递归解析器"），以避免通过明文DNS查询访问的网站泄露。要使用Firefox实现这一点，您只需按照本页上的说明操作即可。Mozilla建议在模式"2"下设置可信递归解析器，这意味着，无论出于什么原因，对TRR的DNS查询失败，都将使用系统的DNS解析程序重试。这有助于避免由于DNS错误配置而破坏您的web浏览，但是如果DNSSEC签名验证失败，Firefox也会退回到系统解析程序，这可能会影响用户的安全性和隐私性，因为查询将通过明文DNS重试。这是因为，来自DNS解析程序的任何DNS故障（包括DNSSEC故障）都是由DNS SERVFAIL返回代码标识的，这对于Firefox来说不够精确，无法区分不同的故障场景。我们正在寻找在我们的1.1.1.1解析程序上解决这个问题的选项，以便给Firefox和其他DNS客户端提供更多关于DNS失败类型的信息，以便在适当的时候避免回退行为。现在一切就绪，继续访问我们的浏览体验安全检查页面，然后单击"检查我的浏览器"按钮。现在应该可以看到如下结果：注意：当您在关于：配置到对于ESNI&TRR设置，您将需要硬刷新检查页以确保建立新的TLS连接。我们计划在以后的更新中修复此问题。要测试Cloudflare域上的加密SNI支持，可以访问"/cdn cgi/trace"页面，例如，https://www.cloudflare.com/cdn-cgi/trace（更换网站你自己的域名）。如果浏览器加密了SNI，您应该在跟踪输出中看到SNI=encrypted。在电线上您还可以更进一步，从它的git存储库下载并构建最新的Wireshark代码（这个特性还没有稳定发布，所以现在需要从源代码构建）。这将允许您在访问支持ESNI的网站（例如。https://cloudflare.com).这是普通TLS连接使用纯文本SNI时的外观：又来了，但这次是加密的SNI扩展：退路正如我们在前面的文章中提到的，可能会出现客户端获取的DNS记录与TLS服务器拥有的有效密钥不匹配的情况，在这种情况下，使用ESNI的连接将无法建立。例如，如果权威DNS服务器和TLS服务器不同步（例如，TLS服务器旋转自己的密钥，但DNS记录没有相应地更新），则可能会发生这种情况。但这也可能是外部因素造成的，例如，缓存DNS解析程序如果不适当地尊重权威服务器设置的TTL，则可能会提供过时的ESNI记录，即使权威服务器是最新的。当这种情况发生时，Firefox将无法连接到网站。我们在Cloudflare edge网络上解决这个问题的方法是简单地让TLS终端堆栈保留过去几个小时内有效ESNI密钥的列表，而不仅仅是最新和最新的密钥。这允许TLS服务器解密客户端发送的加密SNI，即使使用稍微过时的DNS记录来生成SNI。为了尽可能减少ESNI密钥的可用性，需要尽可能多地保持ESNI密钥的安全性和服务的安全性。虽然加密的SNI规范尚未最终确定，但仍有一些实验空间，一个建议的解决方案将允许服务器检测故障并向客户端提供新的ESNI记录，然后客户端可以使用新接收的记录再次尝试连接，而无需完全禁用ESNI。虽然这看起来很简单，但实际上需要考虑很多事情：服务器需要向客户端提供一个证书，这样客户端就可以确保连接不会被拦截，但同时服务器不知道要服务哪个证书，因为它无法解密和检查SNI，这就需要某种"后备证书"。此外，任何此类回退机制都不可避免地会给连接握手增加额外的往返行程，这将否定tls1.3引入的主要性能改进之一（即更短的握手）。结论就我们而言，随着规范的发展，我们将继续试验和改进我们的实现，以使加密的SNI为我们的客户和用户提供最好的工作。