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协议普及的时候，大部分的网络隐私安全问题都会随之解决。