我以为加密 DNS 保护了我的隐私，直到我看到了 ISP 还能看到什么

我选择了 AdGuard Home 和加密的 DNS-over-HTTPS 来保护我的家庭网络，以为这是阻止任何人窥探我在线活动的最后一道防线。我甚至验证了查询是以加密方式传输的，而不是仅仅相信设置面板。但这只在 DNS 查找那一步管用。出于好奇，我想看看 DNS 查找之后会发生什么。那时我才意识到，加密 DNS 解决的问题，跟我想的根本不是一回事。

加密 DNS 并没有说谎

它只是解决了另一个问题

我在 DNS 上折腾了不少。我从 Pi-hole 开始，就是为了在全网屏蔽广告。然后我转向 Pi-hole + dnscrypt-proxy 来实现加密的 DNS-over-HTTPS。接着我改用 AdGuard Home (AGH) 来简化整套方案。之后，我临时切换到 Technitium，以获得更好的功能，特别是原生递归解析。但 Technitium 维护起来太费劲，所以我换回了 AGH，但用 Unbound 来处理递归解析。最后，现在我在用 AGH，有时搭配 Unbound，但主要使用 Quad9 DoH。

咱们先聊两句 DNS。传统的 DNS 查询以明文传输，把我的网络元数据暴露在外。一旦查询离开我的网络，我的 ISP 或路径上的任何人都能看到我查找的每一个主机名。DoH 或 DNS-over-HTTPS 本质上就是为了解决这个问题而设计的。例如，在我目前 AGH + Quad9 DoH 的设置中，一旦 AGH 将查询转发到上游，它就已经处于到 Quad9 的加密 HTTPS 连接之内了。我部署了 DoH 并在我的设置上进行了验证，觉得这样就能万无一失地不让 ISP 知道我在干什么。

我最初的假设是，当看不到 DNS 请求的时候，我的 ISP 可能也无法判断我访问了哪些网站。那时，我以为我已经移除了浏览元数据的最大来源。数据可能留在我自己的网络和我信任的 DoH 提供商之内。不过，我的好奇心并没有就此停止。我已经搞清楚了：IP 地址一旦确定，浏览器就开始建立 HTTPS 连接。我觉得那才是该盯着看的地方，于是我开始观察 TLS 握手。

无人加密的那个字段

你的浏览器仍然会宣告它正在呼叫谁

好吧，AGH 把查询请求通过加密的 HTTPS 连接发了出去，Quad9 对其进行了解析，DNSSEC 确保了这些查询中途没被人动过手脚。最后，浏览器拿到了目标 IP 地址。接下来发生了什么？我很好奇浏览器在发起 HTTPS 连接的时候到底发了些什么出去。我搜了好几次怎么才能看到接下来的过程，后来发现，能最直观地帮我解答这个问题的工具就是 Wireshark。

我立刻使用 Homebrew 在我的 Mac 上安装了 Wireshark（brew install wireshark）。然后我特意用 tshark 命令抓了“tcp port 443”和“tls.handshake.type == 1”的包。结果跟我想的完全不一样。我看到了熟悉的名字：reddit.com、google.com 和 xda-developers.com，因为抓包那会儿我正好访问过这几个网站。然后我看到了一大批我压根没输过的域名：adblockplus.org、cdn-apple.com、grcv.io、sentinelpro.com，以及许多我第一次见到的域名。我的第一个想法是：这些东西怎么还能被看到？我使用的是 DoH；这些本应被隐藏起来。就是从这时候开始，我原来的认知开始站不住脚了。

sudo tshark -i en0 -f "tcp port 443" -Y "tls.handshake.type == 1"

当我查看数据包捕获时，我注意到了一个我以前从来没仔细琢磨过的词——SNI。我快速谷歌了一下，大概是这么回事。HTTPS 会加密内容，但即使在完整加密开始之前，浏览器也会发送 TLS Client Hello。TLS Client Hello 是浏览器为发起连接而发送给服务器的第一条消息。而这条消息包含服务器名称指示（SNI）。服务器为什么还需要 SNI 呢？因为在万维网上，许多网站共享同一个 IP 地址——比如共享主机、共享代理、关联站点之类的——所以 SNI 被用来区分它们。

所以，即使DNS是端到端加密的，解析后的主机名仍然会在TLS握手期间出现。而像我ISP这样的人，只要观察连接就能轻松看到目标域名。他们无法读取我正在请求的网页的实际内容，但可以读取目标地址。

搞清楚这些之后，我发现了一件挺讽刺的事：这事儿对我来说根本不新鲜。我自己搭的Pangolin用的就是同一个协议。Traefik反向代理使用SNI来决定哪个自托管服务应该接收传入的连接。只是我从来没真正站在另一方的角度想过这意味着什么。最终我意识到：当我的浏览器仍然宣告我正在访问哪里时，整个DNS加密努力又有什么用呢？我这爱折腾的脑子立马就想：如果SNI是泄漏点，它是不是也能被加密？

ECH补上了这个缺口（大体上）

不是所有人都知道这回事

“SNI可以被加密吗？”带着这个问题，我简单谷歌了一下，又翻了几个博客和一堆技术论坛。答案是肯定的。加密客户端问候（ECH），以前叫加密SNI，旨在加密客户端问候中的SNI部分。每篇博客和帖子都不忘说明：ECH只加密TLS握手中包含真实服务器名称的那部分，而不是整个客户端问候消息。听起来就像是补上了缺的那块拼图。

然后我开始处理“如何”部分。如果这就是解决方案，我应该怎么做来实现它？这得从两头下手——我要请求的服务器得开启这个协议，而我使用的客户端，也就是浏览器，应该支持 ECH。客户端部分很简单，因为大多数浏览器已经支持该协议，无论是 Safari、Firefox 还是 Chrome（Chromium 也是）。不过，服务器部分不是我能够直接控制的。它取决于服务器配置。

简单查了查，我发现采用率仍然很低，当时 Cloudflare 是唯一一家真正大规模使用它的主要服务商。Cloudflare 是占主导地位、覆盖范围最大的支持 ECH 的 CDN。其他主要 CDN 都还没真正跟上。而且据我了解，Cloudflare 在所有套餐上自动强制启用它，站长没法关掉。我的许多网站已经在 Cloudflare 上，甚至有几个是免费套餐，所以正好可以验证一下我的想法。

我首先运行一个简单的 kdig 命令来检查我的域名是否启用了 ECH。输出结果里能看到 ECH 密钥。然后就开始实际测试了。我同时运行带有“tcp port 443”和“tls.handshake.type == 1”的 tshark 命令，并在 Chrome 上打开我的网站。抓到的数据包证实了我的想法；Client Hello 里显示的不是我真实的主机名，而是 cloudflare-ech.com，而目标 IP 保持不变。

kdig +short TYPE65

然后我尝试测试另一个域名；它没有启用 ECH。这让我又去查了一圈，根据我查到的情况，我基本可以确定在付费套餐中，ECH 是一个可选开关，而不是默认启用的。我没法亲眼确认这个开关的状态，因为那个域名在我主机商管理的付费 Cloudflare 套餐下面。

最终，浏览器支持现在大体上已经到位，但这只是一方面。DNS 提供商、CDN/Web 服务器以及网站本身都必须支持 ECH。只有这些条件全部满足，光靠加密 DNS 无法完全隐藏你的在线活动。

已加密，但尚未隐形

我的 DNS 配置本身没问题。问题出在我对加密 DNS 到底保护了什么的理解上。加密 DNS 正在做它本该做的事——把明文 DNS 查询从流程中去掉。它从来就不是为了提供完整的浏览隐私。事实证明，ECH 正是补上最后一环的关键，但这取决于另一端的服务器有没有开。说到底，加密 DNS 并不是没有用——我仍然开着它，只是不再把它当成完整的隐私保护了。