图解基于 HTTPS 的 DNS

用户面临的隐私和安全隐患与日俱增。 在 Mozilla，我们密切关注这些威胁。 我们相信我们有责任尽全力保护 Firefox 用户及其数据。

一些公司和组织想要秘密收集用户数据并拿来出售。 这就是为什么我们添加了跟踪保护并创建了 Facebook 容器扩展。 接下来几个月在保护用户数据方面我们会采取更多的措施。



另外两项要添加的保护措施：

• 基于 HTTPS 的 DNS，这是我们倡导的一项新的 IETF 标准方案
• 可信递归解析器，一种新的解决 DNS 安全的方案，该方案由我们与 Cloudflare 合作提供

通过这两项举措，逐渐解决了 35 年前创建的域名系统中一直存在的数据泄露问题。 我们希望你能帮忙测试这两个方案。 那么来看看如何通过基于 HTTPS 的 DNS 和可信递归解析器来保护我们的用户。

但首先，让我们看看网页是如何在互联网中运作的。

如果你对 DNS 和 HTTPS 的工作原理已经非常了解，那么可以跳至基于HTTPS 的DNS 的好处。

什么是 HTTP？

当我们解释浏览器如何下载网页时，通常会这样解释：

1. 浏览器向服务器发出 GET 请求。
2. 服务器发送一个响应，该响应是一个包含 HTML 的文件。



这个系统被称为 HTTP。

但是这张图有点过分简化了。 浏览器不会直接与服务器通话。因为浏览器和服务器可能并不接近。

相反，服务器可能远在千里之外。 因此你的电脑和服务器之间不可能存在直接连接。



从浏览器发出的请求需要经过很多次转手才能到达服务器。 对于从服务器返回的响应也是如此。

这就好比课堂上传递纸条。 纸条会表明应该传递给谁。 写下纸条的学生把纸条传递给相邻的学生。 然后，这个学生又把纸条传递给他相邻的学生 - 可能不是最终的接收者，但一定是到达接受者方向上的某个学生。



问题在于沿路的任何人都可以打开纸条。 而且没有办法事先确定纸条的传递路径，所以不确定会有哪些人访问到纸条。

纸条最后可能会落入想要干坏事的人手上.....

就像对所有人公开了纸条的内容一样。



或者改变响应。



为了解决这些问题，创建了一个新的安全版本的 HTTP，即 HTTPS。 使用 HTTPS，就像每条消息都上了一个锁。



浏览器和服务器都知道该锁的组合，除此之外没有任何人知道。

这样，即使消息在多个路由器之间传递，只有你和网站能够读取到内容。

这解决了很多安全问题。 但是浏览器和服务器之间仍然存在一些未加密的消息。 这意味着消息传递的路径上仍然有人可以窃取你的消息。

在与服务器建立连接的过程中，数据仍然有可能暴露。 当将初始消息发送到服务器时，也会发送服务器名称（在名为“服务器名称指示”的字段中）。 这让运行了多个站点的服务器仍然知道应该与谁通信。 此初始请求的一部分设置了加密，但初始请求本身未加密。

数据暴露的另一个地方是在 DNS 中。 但什么是 DNS？

什么是 DNS？

在上面的图解中，纸条接收者的名字必须放在纸条外面。 对于 HTTP 请求也是如此......HTTP 请求需要指明目的地。

但是不能为 HTTP 请求使用名字。 没有一个路由器会知道你在说什么。 相反，必须使用 IP 地址。 通过 IP 地址中间的路由器就知道应该将请求往哪发。



这会导致问题。 你不会希望用户必须记住网站的 IP 地址。 相反，你希望能够给你的网站一个吸引人的名字...... 用户可以记住的东西。

这就是我们拥有域名系统（DNS）的原因。 浏览器使用 DNS 将站点名称转换为 IP 地址。 这个将域名转换为 IP 地址的过程，称为域名解析。



浏览器是如何做到这一点？

一种选择是拥有一个大名单，比如浏览器中的电话簿。 但是，随着新的网站上线，或者当网站迁移到新的服务器时，很难将该列表保持在最新状态。

因此，不是有一个记录所有域名的列表，而是有很多较小的列表，这些列表相互关联。 这使他们能够独立管理。



为了获得与域名相对应的 IP 地址，必须找到包含该域名的列表。 像寻宝一样。

对于英文版维基百科（en.wikipedia.org）这样的站点来说，它们是如何“寻宝”的？

我们可以将这个域分成几部分。



通过这些部分，我们可以搜索包含该网站 IP 地址的列表。 不过，我们需要一些帮助。 为我们寻找 IP 地址的工具称叫解析器。

首先，解析器与一个称为根 DNS 的服务器通信。 它知道几个不同的根 DNS 服务器，因此它将请求发送给其中的一个。 解析器向根 DNS 服务器询问哪里可以找到有关 org 顶级域名的更多信息。

根 DNS 将为解析器提供一个知道.org 地址的服务器的地址。



下一个服务器叫做 top-level domain 顶级域名服务器 (TLD)。 TLD 服务器知道所有以.org 结尾的二级域名。

但它并不知道 wikipedia.org 下的子域名，所以它不知道 en.wikipedia.org 的 IP 地址。

TLD 名称服务器将告诉解析器询问维基百科的名称服务器。



解析工作快完成了。 维基百科的名字服务器及权限服务器。 它知道 wikipedia.org 下的所有域名。 所以这个服务器知道 en.wikipedia.org 和其他子域名，比如德文版 de.wikipedia.org。 权限服务器通知解析器哪个 IP 地址具有该站点的 HTML 文件。



解析器会将 en.wikipedia.org 的 IP 地址返回给操作系统。

这个过程被称为递归解析，因为你必须来回询问不同的服务器，基本上是同一个问题。

我们需要这样的解析器来完成网络请求。 但浏览器如何找到这个解析器？ 一般来说，它要求计算机的操作系统提供可用的解析器进行设置。



操作系统如何知道使用哪个解析器？ 有两种可能的方法。

你可以为你的计算机配置一个信任的解析器。 但很少有人这样做。

相反，大多数人只是使用默认值。 默认情况下，操作系统将只使用网络告诉它的任何解析器。 当计算机连接到网络并获取其 IP 地址时，网络会推荐一个解析器。



这意味着解析器每天可以更改多次。 例如前往咖啡店参加下午的工作会议，就可能与早上使用的解析器不同。 即使你配置了解析器，这也是正确的，因为 DNS 协议没有安全性。

DNS 如何被利用？

那么这个系统如何让用户安全变得脆弱？

通常解析器会告诉每个 DNS 服务器你正在寻找哪个域名。 该请求有时会包含你的完整 IP 地址。 或者，如果不是完整的 IP 地址，请求中通常会包含你的大部分 IP 地址，这些 IP 地址可以轻松地与其他信息结合起来以找出你的身份。



这意味着进行域名解析的每台服务器都会查看你要查找的网站。 但更重要的是，这也意味着通往这些服务器的任何人都可以看到你的请求。

这个系统有几种方式会使用户的数据处于危险之中。 两大主要的风险是跟踪和欺骗攻击。

跟踪

就像上面所说的那样，很容易获取全部或部分 IP 地址信息并找出谁在请求该网站。 这意味着 DNS 服务器和通向该 DNS 服务器的路径上的任何其他路由器 (路径路由器) 都可以创建一个关于你的文件。 他们可以创建一个你访问过网站的记录。

而且这些数据很有价值。 许多人和公司会花很多钱看你在浏览什么。



即使不必担心可能的恶意 DNS 服务器或路径路由器，仍有数据被收集的风险。因为解析器本身 - 网络提供给你的 - 可能并不可靠。

即使你信任网络推荐的解析器，可能也只在家中使用该解析器。就像之前提到的那样，每当你去一家咖啡店或酒店或者使用接入其他网络时，你可能会使用不同的解析器。谁知道它的数据收集政策是什么？

除了收集数据，然后在你不知情或不同意的情况下进行销售之外，还有更危险的方式。

欺骗攻击

借助欺骗，DNS 服务器和你之间的路径上的某个人将更改响应。而不是告诉你真正的 IP 地址，欺骗者会给你一个错误的 IP 地址。这样，他们可以阻止访问真实网站或将你引导至欺诈网站。



再次，解析器本身可能使坏。

例如，假设在 Megastore 购物。你想做一个价格对比，看看是否能够在 big-box.com 上获得更便宜的价格。

但是如果你使用 Megastore 的 WiFi，你可能正在使用他们的解析器。该解析器可能会劫持对 big-box.com 的请求并对谎称该网站不可用。

如何通过可信递归解析器（TRR）和基于 HTTPS 的 DNS（DoH）解决此问题？

在 Mozilla，我们强烈认为我们有责任保护用户及其数据。我们一直在努力解决这些漏洞。

我们引入了两项新功能来解决这个问题 - 可信递归解析器（Trusted Recursive Resolver ）和基于 HTTPS 的 DNS（DNS over HTTPS）。因为目前确实有三个威胁需要解决：

1. 可能会使用跟踪你请求的不可信的解析器，或者篡改来自 DNS 服务器的响应。
2. 路径上路由器可以以相同的方式跟踪或篡改。
3. DNS 服务器可以跟踪你的 DNS 请求。



如何解决这些问题？

1. 使用可信递归解析器避免不可靠的解析器。
2. 通过基于 HTTPS 的 DNS 防止路径上的窃听和篡改。
3. 传输尽可能少的数据，以保护用户免受匿名处理。

使用可信递归解析器避免不可靠的解析器

当网络提供了不可信的解析器来收集你的数据或进行欺骗攻击，网络服务的提供者依然可以全身而退，因为很少有用户知道风险或如何保护自己。

即使对于了解风险的用户，个人用户也很难与他们的 ISP 或其他实体进行协商，以确保他们的 DNS 数据得到负责任的处理。

但是，我们花时间研究这些风险...... 并且我们有了谈判权力。 我们努力寻找一家公司可以合作来保护用户的 DNS 数据。 我们找到了一个： Cloudflare 。

Cloudflare 通过专业用户隐私政策提供递归解析服务。他们承诺在 24 小时后丢弃所有可识别个人身份的数据，并且决不会将这些数据传递给第三方。并会定期进行审计，以确保数据按预期清除。

现在，我们有一个可以信赖的解析器来保护用户的隐私。这意味着 Firefox 可以忽略网络提供的解析器，并直接转到 Cloudflare。有了这个可靠的解析器，我们不必担心流氓解析器出售我们的用户数据或用欺骗性 DNS 来欺骗我们的用户。

我们为什么选择这样一个解析器？ Cloudflare 与我们一样致力于构建隐私优先的 DNS 服务。他们与我们合作建立了一个 DoH 解决方案服务，以透明的方式为用户提供服务。他们一直非常乐意为服务添加用户保护，所以我们很高兴能够与他们合作。

但这并不意味着你必须使用 Cloudflare。用户可以配置 Firefox 使用他们想要的任何支持 DoH 的递归解析器。随着更多产品的出现，我们会让解析器的切换变得简单。

通过基于 HTTPS 的 DNS 防止路径上的窃听和篡改

虽然解析器不是唯一的威胁。路径上路由器可以跟踪和欺骗 DNS，因为他们可以看到 DNS 请求和响应的内容。但是互联网已经有了确保路径上路由器不能像这样窃听的技术。这是我之前提到的加密技术。

通过使用 HTTPS 加密 DNS 数据包，可以确保没有人能够监视用户正在做出的 DNS 请求。

传输尽可能少的数据以保护用户免受匿名处理

除了提供使用 DoH 协议进行通信的可信解析器之外，Cloudflare 正在与我们合作，使其更安全。

通常情况下，解析器会将整个域名发送给每个服务器 - 根 DNS 服务器，TLD 名称服务器，二级名称服务器等。但是 Cloudflare 会做一些不同的事情。它只会发送与当前正在与之通话的 DNS 服务器相关的部分。这被称为 QNAME 最小化。



解析器通常也会在请求中包含你的 IP 地址的前 24 位。 这有助于 DNS 服务器知道你的位置，并选择离你更近的 CDN。 但是这些信息可以被 DNS 服务器用来将不同的请求链接在一起。

Cloudflare 不会这样做，而是从用户附近的一个 IP 地址发出请求。 这提供了地理位置，而无需将其绑定到特定用户。 除此之外，我们正在研究如何以隐私敏感的方式更好的实现，非常细粒度的负载平衡。

这样做 - 删除域名中不相关的部分并且不包括你的 IP 地址 - 意味着 DNS 服务器所收集的关于你的数据要少得多。



基于 DoH 的 TRR 还未解决的问题

通过这些解决方案，我们减少了可以看到你访问网站的人数。但是这并不能完全消除数据泄漏。

在执行 DNS 查找到 IP 地址后，你仍然需要连接到该地址的 Web 服务器。为此，发送初始请求。该请求包含一个服务器名称指示，该信息指出要连接的服务器上的哪个站点。这个请求是未加密的。

这意味着你的 ISP 仍然可以找出正在访问的网站，因为它正好在服务器名称指示中。另外，将来自浏览器的初始请求传递给 Web 服务器的路由器也可以看到这些信息。

但是，一旦你建立了与 Web 服务器的连接，那么一切都是加密的。并且这个加密的连接可以用于该服务器上托管的任何站点，而不仅仅是最初要求的那个站点。

这称为 HTTP / 2 连接合并，或简单地连接重用。当你打开一个连接到支持它的服务器时，该服务器会告诉你它托管了哪些其他的站点。然后，你可以使用现有的加密连接访问其他网站。

这样有什么好处？ 无需启动新连接即可访问这些其他网站。 这意味着你不需要发送未加密的初始请求，其服务器名称指示正在访问的站点。 这样可以访问同一台服务器上的任何其他站点，而无需透露你正在查看的站点到网络服务提供商和路径路由器。

随着 CDN 的兴起，越来越多的独立站点由一台服务器提供服务。 由于可以打开多个合并连接，因此可以同时连接到多个共享服务器或 CDN，访问不同服务器上的所有站点而不会泄露数据。 这意味着隐私保护越来越有效。

现状

现在我们鼓励你在 Firefox 中开启基于 HTTPS 的 DNS。

我们希望将其作为所有用户的默认设置。 我们相信，无论用户是否了解 DNS 泄漏，每个用户都应该享有这种隐私和安全。

但这是一个巨大的变化，我们需要首先对其进行测试。 这就是进行该研究的原因。 我们要求一半的 Firefox Nightly 用户帮助收集有关性能的数据。

现在将使用的是默认解析器，但我们也会将请求发送到 Cloudflare 的 DoH 解析器。 然后会比较两者，以确保一切都按照我们的预期工作。

对于研究中的参与者，Cloudflare DNS 响应将不会被使用。 我们只是检查一切正常，然后扔掉 Cloudflare 响应。



我们非常感谢得到 Nightly 用户的支持 - 帮助每天测试 Firefox 的用户 - 同时也希望能帮助我们对此进行测试。

关于 Lin-Clark

Lin 是 Mozilla 开发者关系团队的一名工程师。 她使用 JavaScript，WebAssembly，Rust 和 Servo，同时会绘制代码图解。