运营商 sni 服务器,加密或者丢失：加密SNI的工作机制

原标题：加密或者丢失：加密SNI的工作机制

今天，我们宣布支持加密SNI，这是TLS 1.3协议的扩展，通过防止路径上的观察者(包括ISP、咖啡店老板和防火墙)拦截TLS服务器名称指示(SNI)扩展并用其来判断用户正访问哪些网站，从而提高互联网用户的隐私。

加密SNI以及Cloudflare免费提供的其他互联网安全特性将使在互联网上审查内容和跟踪用户变得更加困难。继续阅读，了解它的工作机制。

SNWhy？

最初在2003年标准化的TLS服务器名称指示(SNI)扩展允许服务器在同一组IP地址上托管多个启用TLS的网站，方法是要求客户端指定在初始TLS握手期间想要连接到哪个站点。如果没有SNI，服务器无从知道相关信息，比如，向客户端提供哪些证书，或者将哪个配置应用于连接。

客户端将包含所连接的站点主机名的SNI扩展添加到ClientHello消息。它在TLS握手期间向服务器发送ClientHello。不幸的是，由于客户端和服务器此时不共享加密密钥，ClientHello消息发送时未加密。

未加密SNI的TLS1.3

这意味着路径上的观察者(例如，ISP、咖啡店老板或防火墙)可以拦截明文ClientHello消息，并确定客户端试图连接到哪个网站。这样观察者就能跟踪用户正在访问的站点。

然而，通过SNI加密，即使ClientHello的其余部分以明文发送，客户端也能加密SNI。

加密SNI的TLS1.3

那么，为什么原始SNI在过去无法加密、而现在可以加密了？如果客户端与服务器尚未协商出一个加密密钥，那加密密钥从何而来？

如果先有鸡，再有鸡蛋，那鸡从何而来？

正如许多其他互联网特征一样，答案很简单：“DNS”。

服务器在知名DNS记录中发布一个公钥，客户端在连接前可以获取该公钥(正如它对A、AAAA和其他记录所做的那样)。然后，客户端将ClientHello中的SNI扩展名替换为“加密SNI”扩展，该扩展正是原始的SNI扩展，但使用由服务器公钥导出的对称加密密钥加密过，如下所述。拥有私钥并可以导出对称加密密钥的服务器则能够解密该扩展，从而终止连接(或者将其转至后端服务器)。由于只有客户端以及它所连接的服务器能够导出加密密钥，所以加密的SNI无法被第三方解密或访问。

需要注意的是，这是TLS 1.3及以上版本的扩展，不适用于该协议之前的版本。原因非常简单：TLS 1.3(并非没有问题)更改的内容之一是将服务器发送的证书消息移至TLS握手的加密部分(在1.3之前，以明文形式发送)。如果不对该协议进行这种基本的更改，攻击者仍能够通过简单地观察线上发送的明文证书来确定服务器的身份。

底层的密码体制涉及使用Diffie-Hellman密钥交换算法，该算法允许客户端与服务器通过不受信任的渠道生成共享的加密密钥。因此，加密的SNI密钥在客户端通过使用服务器的公钥(实际上是Diffie-Hellman半静态密钥共享的公共部分)和客户端自身动态生成的临时Diffie-Hellman共享的私有部分来计算，并在ClientHello发送至服务器后立即丢弃。附加数据(例如客户端发送的一些密码参数，作为ClientHello消息的一部分)也被额外混合到加密过程中。

这样，客户端的ESNI扩展不仅包括实际加密的SNI位，还包括客户端的公钥共享、用于加密的密码组以及服务器ESNI DNS记录的摘要。另一方面，服务器使用自己的私钥共享及客户端共享的公共部分来生成加密密钥和解密扩展。

虽然这可能看似过于复杂，却保证了加密密钥被加密地绑定到生成的特定TLS会话中，并且无法在多个连接间重复使用。这使能够观察客户端发送的加密扩展的攻击者无法轻易捕获，并在单独的会话中重放给服务器，进而揭露用户试图连接的网站身份(这被称为“剪切粘贴”攻击)。

然而，服务器私钥的损害将它生成的所有ESNI对称密钥置于危险之中(这使得观察者能够解密之前收集到的加密数据)，这就是为什么Cloudflare自己的SNI加密使用每小时轮换服务器密钥来提高正向加密，但记录前几小时的密钥以供DNS缓存和复制延迟，这样一来，即使密钥稍微过时，客户端仍然能够正常使用ESNI(但最终所有密钥都会被丢弃和忘记)。

稍等，DNS？真的吗？

敏锐的读者可能已经意识到，仅仅使用DNS(默认情况下是未加密的)会让整个加密SNI的想法毫无意义：无论加密SNI是否被使用过，路径上的观察者只需观察客户端发送的明文DNS查询便能够确定客户端正在连接到哪个网站。

但是，随着DNS特性的引入，例如基于TLS的DNS(DoT)和基于HTTPS的DNS(DoH)，以及向用户提供这些特征的公共DNS解析器(例如Cloudflare自己的1.1.1.1)，DNS查询现在可以通过审查员和跟踪员的窥探进行加密和保护。

然而，虽然在某种程度上，来自DoT/DoH DNS解析器的响应是可信的(尽管存在恶意解析器)，但是下定决心的攻击者仍然可能通过拦截解析器与权威DNS服务器的通信并注入恶意数据来破坏解析器的缓存。也就是说，除非权威服务器及解析器都支持DNSSEC[1]。顺便说一下，Cloudflare的权威DNS服务器可以对返回到解析器的响应进行签名，并且1.1.1.1解析器还可以对其进行验证。

IP地址呢？

虽然现在DNS查询和TLS SNI扩展都可以受到路径上攻击者的保护，但是仍然可以简单地通过查看用户设备通信量上的目的地IP地址来确定用户正在访问哪些网站。由于许多Cloudflare域共享同一组地址，因此我们的一些客户在一定程度上受到了保护，但是这还不够，我们需要做更多的工作以便在更大程度上保护终端用户。敬请关注未来Cloudflare在该课题上的更多更新。

在哪里注册？

使用我们的名称服务器，加密SNI现在可以在所有Cloudflare区域免费启用，因此您无须做任何事情就可以在Cloudflare网站上启用它。在浏览器方面，Firefox的朋友告诉我们，他们希望本周将加密SNI支持加到Firefox Nightly(请记住，加密SNI规范仍在开发中，尚不稳定)。

通过访问encryptedsni.com，您可以查看浏览体验的安全性。您是否正在使用安全的DNS？您的解析器验证DNSSEC签名吗？您的浏览器支持TLS 1.3吗？您的浏览器加密SNI了吗？如果所有这些问题的答案都是“是”，那么您就可以安然入睡，因为您的浏览是受到保护的。

结论

加密SNI与TLS 1.3、DNSSEC及 DoT/DoH堵塞了少数几个允许在因特网上进行监视和审查的漏洞之一。为了达成免受监视的互联网，仍有很多工作要做，但是我们正在(慢慢地)靠近。返回搜狐，查看更多

责任编辑：