今天，我们宣布了对加密SNI的支持，这是tls1.3协议的一个扩展，通过阻止包括isp、咖啡店所有者和防火墙在内的在线观察者拦截TLS服务器名称指示（SNI）扩展并使用它来确定用户是哪些网站，从而提高了互联网用户的隐私访问。加密SNI公司，加上Cloudflare已经免费提供的其他互联网安全功能，将使互联网上的内容审查和用户追踪变得更加困难。继续读下去，了解它是如何做到的工作。为什么？TLS服务器名称指示（SNI）扩展最初是在2003年标准化的，它允许服务器在同一组IP地址上托管多个启用TLS的网站，方法是要求客户端在初始TLS握手期间指定要连接到的站点。如果没有SNI，服务器将不知道要为客户机提供哪个证书，或者将哪个配置应用于连接。那个客户机将包含所连接站点主机名的SNI扩展添加到ClientHello消息中。它在TLS握手期间将ClientHello发送到服务器。不幸的是，ClientHello消息是未加密的，因为客户端和服务器在发送时不共享加密密钥点.TLS1.3对于未加密的sni，这意味着在途观察者（例如，ISP、咖啡店老板或防火墙）可以拦截明文ClientHello消息，并确定客户端要连接的网站。它允许观察者跟踪用户所在的站点拜访。但是使用SNI加密，客户机对SNI进行加密，即使ClientHello的其余部分以明文形式发送。tls1.3和加密的SNI为什么原来的SNI以前不能加密，但现在可以了？如果客户端和服务器尚未协商加密密钥，那么加密密钥从何而来？如果鸡必须先于蛋，你把鸡放在哪里？与许多其他互联网功能一样，答案很简单就是"DNS"。服务器在已知的DNS记录上发布一个公钥，客户端可以在连接之前获取它（就像它已经对a、AAAA和其他记录那样）。然后，客户端将ClientHello中的SNI扩展替换为"加密的SNI"扩展，该扩展不是原来的SNI扩展，而是使用从服务器的公钥派生的对称加密密钥进行加密，如下所述。拥有私钥并可以派生对称加密密钥的服务器，然后可以解密扩展，从而终止连接（或将其转发到后端服务器）。由于只有客户端和它所连接的服务器可以派生加密密钥，所以加密的SNI不能被第三方解密和访问派对。它需要注意的是，这是TLS版本1.3及更高版本的扩展，与以前版本的协议不兼容。原因很简单：tls1.3引入的一个更改（并非没有问题）意味着将服务器发送的证书消息移动到TLS握手的加密部分（在1.3之前，它是以明文形式发送的）。如果不改变协议，攻击者仍然可以通过观察在上发送的明文证书来确定服务器的身份电线。那个底层加密机制涉及使用Diffie-Hellman密钥交换算法，该算法允许客户端和服务器通过不可信的通道生成共享加密密钥。因此，加密的SNI加密密钥在客户端通过使用服务器的公钥（实际上是Diffie-Hellman半静态密钥共享的公共部分）和客户端自己动态生成的短暂Diffie-Hellman共享的私有部分来计算，ClientHello被发送到服务器。如客户端的一些加密数据（如加密数据）也被混合发送到客户端量度一下客户端的ESNI扩展将不仅包括实际加密的SNI位，还包括客户端的公钥共享，即它用于加密的密码套件以及服务器的ESNI DNS记录摘要。另一方面，服务器使用它自己的私钥共享和客户端共享的公共部分来生成加密密钥并对扩展名。While这可能看起来过于复杂，这可以确保加密密钥以加密方式绑定到为其生成的特定TLS会话，并且不能跨多个连接重用。这可以防止能够观察到客户端发送的加密扩展名的攻击者简单地捕获它并在单独的会话中将其重放到服务器上，从而揭开用户试图连接的网站的身份（这称为"剪切粘贴"攻击）。但是，服务器私钥的泄露将导致所有ESNI由此产生的对称密钥处于危险之中（这将允许观察者对先前收集的加密数据进行解密），这就是为什么Cloudflare自己的SNI加密实现每小时旋转一次服务器的密钥，以提高前向保密性，但是，在前几个小时跟踪密钥，以允许DNS缓存和复制延迟，这样具有稍微过期密钥的客户端仍然可以使用ESNI而不会出现问题（但最终所有密钥都会被丢弃和遗忘）。但是，等等，DNS？真的吗？观察力强的读者可能已经意识到，仅仅使用DNS（默认情况下是未加密的）会使整个加密SNI的想法变得完全没有意义：一个在路径上的观察者可以通过观察客户端自己发送的明文DNS查询来确定客户端连接到哪个网站，加密的SNI是否是使用或不是。但是随着DNS功能（如DNS over TLS（DoT）和DNS over HTTPS（DoH）的引入，以及向用户提供这些功能的公共DNS解析程序（如Cloudflare自己的1.1.1.1），DNS查询现在可以通过审查员和追踪者的窥探来加密和保护差不多。不过，而来自DoT/DoH的响应DNS解析程序是可以信任的，在一定程度上（尽管存在邪恶的解析程序），但有决心的攻击者仍然有可能通过拦截解析程序与权威DNS服务器的通信并注入恶意数据来毒害解析程序的缓存。也就是说，除非权威服务器和解析程序都支持DNSSEC[1]。顺便说一句，Cloudflare的权威DNS服务器可以对返回到解析程序的响应进行签名，而1.1.1.1解析程序可以进行验证他们。什么关于IP地址？虽然DNS查询和TLS SNI扩展现在都可以被on-path攻击者保护，但是仍然可以通过查看来自用户设备的流量上的目标IP地址来确定用户正在访问哪些网站。由于许多Cloudflare域共享相同的地址集，因此我们的一些客户在一定程度上受到了保护，但这还不够，还需要做更多的工作才能在更大程度上保护最终用户。请继续关注Cloudflare关于中主题的更多更新未来。在哪里我要报名吗？加密的SNI现在可以在所有Cloudflare区域使用我们的名称服务器免费启用，因此您不需要在Cloudflare网站上做任何事情来启用它。在浏览器方面，我们在Firefox的朋友告诉我们，他们希望在本周每晚向Firefox添加加密SNI支持（请记住加密SNI规范仍在开发中，因此还不稳定）加密sni.com你可以检查你的浏览体验有多安全。你在使用安全DNS吗？你的解析器正在验证DNSSEC签名吗？你的浏览器支持TLS1.3吗？你的浏览器加密了SNI吗？如果所有这些问题的答案都是"是"，那么你就可以安心睡觉了，因为你的浏览受到了保护，不会被人窥探眼睛。结论加密SNI与tls1.3、DNSSEC和DoT/DoH一起，填补了互联网上实现监视和审查的少数几个漏洞之一。要想获得一个无监控的互联网，还需要做更多的工作，但我们正在（慢慢地）实现这一点。[1]：需要指出的是，DNSSEC可能会被DNS解析程序和TLD服务器之间的BGP路由劫持所禁用。上周我们宣布了对RPKI的承诺，如果DNS解析程序和tld也实现了RPKI，这种类型的劫持将更多困难。订阅每天更新我们所有生日周的公告。