DNS污染？SNI阻断？全新网络协议保护隐私安全

HTTPS协议的安全缝隙概述

HTTPS协议对网络流量进行了加密，然而这种保护并非完美。事实上，HTTPS体系存在着两个安全缝隙：DNS和SNI，它们依旧使用着明文传输，因此可能会导致隐私泄露等安全风险。

本期视频，我们来介绍一组新诞生的网络技术，看看他们是如何补上这最后一块HTTPS安全体系的拼图。

DNS安全缝隙分析

DNS是一种域名转换为IP地址的服务。

当用户在浏览器输入一个网址时，浏览器会先向DNS服务器发送请求，以获取该网址所对应的IP地址。浏览器拿到IP地址以后，才能进行后续的网络请求。

然而DNS的查询与响应，都是UDP协议的明文传输。这就意味着，可能被网络传输的中间人监听篡改。中间人可以轻易知道用户准备访问哪个网站，用户就会因此泄露隐私。

DNS明文传输演示

这里我使用WireShark这款软件，抓了一下我这台电脑的数据包。在电脑的默认配置下，DNS都是明文传输的。我们可以看到，这里很清晰的显示了我的DNS请求。这里我请求的是QQ.com这个网址，后面是QQ.com对应的IP地址。

攻击者通过抓取DNS数据包，很轻易的就知道我是要访问哪个网站。中间人甚至可以修改DNS的响应结果，故意误导一个错误的IP地址，让浏览器无法正常工作。这种攻击也就是DNS污染。

DNS加密解决方案

为了应对这种安全挑战，两种加密版本的DNS协议诞生了：

DoT利用传输层的安全协议TLS来加密DNS查询，DoT通常在853端口上运行。
DoH则是一种通过HTTPS协议传输DNS查询的方法，它利用了HTTPS协议天然的加密特性来保障数据传输的隐私性与安全性。

这两种方法目前更主流的是DoH，因为DoH的优点显而易见。DoH复用了HTTPS协议，使得DNS查询与普通的web流量是混合在一起的。DoH与HTTPS共用443端口，从而更难被中间人识别攻击。

现在，国内已经有了比较成熟的DoH供应商，比如阿里云、腾讯的DNS Pro等等。国际上也有Cloudflare、谷歌等DoH供应商。

Windows系统DoH配置教程

DoH已经是比较成熟的技术。下面我以Windows 11加阿里云的DoH为例，演示下如何给电脑配置上DoH，从而保护DNS的安全：

我们在电脑的右下角找到自己的网络，点击网络和Internet设置。
这里找到我的WLAN，进来以后点击硬件属性。
找到DNS设置，这里点击编辑。
这里找到IPV4，这里我配置阿里云的公共DNS。
把下面这个DNS over HTTPS(DoH)也就是DoH的功能开起来。
这里点击手动模板开，下面填上阿里云的查询模板，前面是HTTPS，后面是阿里云的IP，然后是dns-query。
这里失败时使用未加密请求，把它开起来。

好，我们保存一下。

我们来测试一下，我们来访问一下这个网址。可以看到WireShark这里面，变成了一个443端口的普通HTTPS请求，请求里面的内容也进行了完全加密。通过抓包，再也不能分析出来访问的是哪个网站了。

SNI安全缝隙分析

Several Name Indication（服务器名称指示）是HTTPS体系中的另一个安全缝隙。在HTTPS的TLS握手过程中，客户端首先需要在服务端请求证书。如果一个服务器上只部署了一个网站还比较好办，如果同一个服务器上部署了多个网站（比如site1、site2、site3），就必须有一个机制来区分客户端（也就是浏览器）要访问哪一个网站。

SNI就是解决这个问题的机制。在SNI协议下面，握手开始的时候，客户端会主动告诉服务器要连接的网站的名字。

比如在图中的这个例子中，客户端在TLS握手过程中主动携带了一个SNI的数据字段，指明自己要连接的网站是site2，服务器则把site2对应的证书发送给客户端，从而完成HTTPS的握手。

SNI明文传输问题

不幸的是，在HTTPS协议中，TLS握手发生在数据的正式传递之前，因此其中的数据都是明文传递的。这就意味着，SNI信息可能会被网络传输中的中间人监听。中间人可以轻易地知道用户准备访问哪个网站，用户因此就会泄露隐私。中间人还可以通过识别SNI的信息，阻断一部分TLS握手的建立，这种攻击也就是SNI阻断。

SNI明文传输演示

我们还是使用抓包软件来演示一下。首先我访问一下Github，然后我们看一下抓包软件。这里我的过滤条件换成Client Hello，也就是客户端你好（客户端问候）。我们可以看到这个数据结构，往下找找到这里，extension里面有一个server name就是Github。这里明显是明文显示出了我要请求的网站。

ESNI解决方案

为了解决SNI明文泄露的问题，一些全新的技术诞生了。首先是ESNI，也就是encrypted SNI（加密SNI）。ESNI在浏览器端通过网站的公钥加密SNI数据（也仅仅只有此部分），来保护SNI的私密性。

不过现在问题来了：SNI发生在TLS的握手阶段，因此ESNI的加密密钥必须在握手阶段之前就送达客户端。这时候我们的DNS服务就又出场了。客户端可以把自己的公钥放在DNS服务器那边，当客户端查询DNS的时候，当然也可以同样获取服务端对应的公钥。

这有点像将房门钥匙放在屋外的密码箱里面。当然，为了公钥传递的安全性，这里的DNS也必须使用DoH，也就是加密的DNS传输公钥，这样才能确保万无一失。客户端拿到公钥以后，可以直接使用公钥加密SNI数据，只有服务器端的私钥才可以解密它，这样就做到了SNI传输的安全保密。

ESNI存在的问题

ESNI仍然存在两个问题：

问题一就是只加密了SNI信息。在TLS握手阶段，还有其他的敏感数据可能会泄露用户隐私，比如ALPN等等。因此ESNI的保护还是不够全面。
问题二是ESNI没有托底机制。如果解密失败，ESNI的服务器会直接终止连接。这种情况常常发生于因为DNS缓存导致公钥更新不及时。

ECH解决方案

为了解决以上问题，一个全新的技术诞生了，也就是ECH（加密客户端问候）。ECH有着更大的野心，不单单是加密SNI，而是要加密整个Client Hello，这样就解决了握手过程中的一切隐私安全问题。

ECH同样使用了DoH进行密钥的分发，但是在上述过程中进行了改进。如果解密失败，ECH服务器会重新提供给客户端一份公钥，供客户端重试连接，这样可以更可靠的达成TLS的握手。

ECH配置演示

ECH是一个新兴的技术，目前只有很少的网站实验性的开启了ECH的功能。我们可以在这个网站测试一下自己的浏览器是否支持ECH。

这是我的一个Chrome浏览器，可以看到这里写着不支持ECH。不支持的原因是我没有在浏览器里面配置DoH（也就是DNS over HTTPS），因为公钥的分发必须依赖DoH。所以我们先把浏览器配置上DoH：

这里我打开Chrome浏览器的设置。
找到DNS相关设置。
这里找到use secure DNS。
我们点击一个自定义的。
这里还是填写阿里云的那个DNS。

然后我重新启动一下Chrome浏览器，刷新一下页面。这里写着"You are using ECH"，那就启动成功了。也就是ECH功能在最新的浏览器里面已经全部默认开启了，我们只需要在浏览器这边配置上DoH就行了。

未来展望：QUIC协议

第三代HTTP协议，也就是QUIC，它是由谷歌公司研发的。QUIC协议在传输层使用了无连接的UDP协议，代替了传统的TCP协议。QUIC协议大幅减少了TLS的握手流程，从而获取了更优的延迟表现。

QUIC协议在设计之初就自带了Hello Client阶段的加密，而且它还提供了一种安全的DNS查询协议。我们可以展望一下，等到HTTP3协议普及的时候，大部分的网络隐私安全问题都会随之解决。