针对用户隐私和安全的威胁正在不断增加。在 Mozilla，我们密切关注这些威胁。我们认为，我们有责任尽一切努力保护 Firefox 用户及其数据。

我们正在对抗那些试图秘密收集和出售用户数据的公司和组织。这就是我们添加 跟踪保护 并创建 Facebook 容器扩展 的原因。在未来几个月，您将看到我们采取更多措施来保护我们的用户。

我们将添加到此列表中的另外两种保护措施是

• DNS over HTTPS，这是我们大力倡导的一项新的 IETF 标准工作
• Trusted Recursive Resolver，一种与 Cloudflare 合作提供的全新安全解析 DNS 的方式

通过这两项举措，我们正在关闭自域名系统创建 35 年以来一直存在的的数据泄露漏洞。我们希望您能帮助我们测试这些漏洞。让我们来看看 DNS over HTTPS 和 Trusted Recursive Resolver 如何保护我们的用户。

但首先，让我们看看网页如何在互联网上移动。

如果您已经了解 DNS 和 HTTPS 的工作原理，可以直接跳到 DNS over HTTPS 如何提供帮助。

HTTP 课程

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

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

此系统称为 HTTP。

但此图有点过于简化。您的浏览器不会直接与服务器通信。这是因为它们可能并不靠近彼此。

相反，服务器可能在数千英里之外。而且您的计算机与服务器之间可能没有直接连接。

因此，此请求需要从浏览器传送到该服务器，并且它将在到达那里之前经过多个环节。从服务器传回的响应也是如此。

我认为这就像孩子们在课堂上互相传递纸条。纸条的外部会写明它应该传递给谁。写纸条的孩子会把它传给他的邻居。然后，下一个孩子把它传递给他们的邻居之一——可能不是最终的接收者，但可能是朝着那个方向的人。

问题在于，路径上的任何人都有可能打开纸条并阅读它。而且无法预先知道纸条将走哪条路径，所以无法知道哪些人会访问它。

它最终可能会落入会做坏事的人手中……

例如，与所有人分享纸条的内容。

或者更改响应。

为了解决这些问题，创建了 HTTP 的一个新的安全版本。这被称为 HTTPS。在 HTTPS 中，这有点像每个消息都带有锁。

浏览器和服务器都知道锁的密码，但中间没有人知道。

这样，即使消息经过中间的多个路由器，只有您和网站才能实际读取内容。

这解决了许多安全问题。但仍然有一些在浏览器和服务器之间传递的消息没有加密。这意味着沿途的人仍然可以窥探您正在做什么。

数据仍然暴露的一个地方是在建立与服务器的连接时。当您向服务器发送初始消息时，您还会发送服务器名称（在名为“服务器名称指示”的字段中）。这使服务器运营商能够在同一台机器上运行多个站点，同时仍然知道您试图与谁通信。此初始请求是设置加密的一部分，但初始请求本身未加密。

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

DNS：域名系统

在上面的传递纸条的比喻中，我说接收者的姓名必须写在纸条的外部。这对于 HTTP 请求也是如此……它们需要说明它们要传递给谁。

但是您不能使用他们的姓名。中间的路由器都不会知道你在说什么。相反，您必须使用 IP 地址。这就是中间的路由器如何知道您要将请求发送到哪个服务器。

这会导致一个问题。您不希望用户记住您的网站的 IP 地址。相反，您希望能够为您的网站提供一个朗朗上口的名称……用户可以记住的东西。

这就是我们拥有域名系统 (DNS) 的原因。您的浏览器使用 DNS 将站点名称转换为 IP 地址。此过程——将域名转换为 IP 地址——称为域名解析。

浏览器如何知道如何执行此操作？

一种选择是在浏览器中提供一个大列表，就像电话簿一样。但是随着新网站上线或网站迁移到新服务器，保持该列表的最新状态将非常困难。

因此，与其有一个跟踪所有域名的大列表，不如说有很多可以相互链接的小列表。这使它们能够独立管理。

为了获取与域名相对应的 IP 地址，您必须找到包含该域名的列表。这样做有点像寻宝。

对于像英文版维基百科这样的网站来说，en.wikipedia.org，这种寻宝活动会是什么样的？

我们可以将此域名分解成几个部分。

有了这些部分，我们就可以寻找包含网站 IP 地址的列表。不过，我们需要在探索中获得一些帮助。我们将用于执行此探索并找到 IP 地址的工具称为解析器。

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

根 DNS 会向解析器提供一个知道有关.org 地址的服务器的地址。

此下一个服务器称为顶级域 (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 地址信息找出谁正在请求该网站。这意味着 DNS 服务器以及通往该 DNS 服务器路径上的任何人都可以创建您的个人资料。他们可以记录他们所见过的您所查询的所有网站。

这些数据是有价值的。许多人和公司会花很多钱来查看您正在浏览的内容。

即使您不必担心可能是恶意 DNS 服务器或路径上的路由器，您仍然有风险将您的数据被收集并出售。这是因为解析器本身（网络为您提供的那个）可能是不可信的。

即使您信任网络推荐的解析器，您可能也只在家里使用该解析器。正如我之前提到的，无论您去咖啡馆、酒店，还是使用任何其他网络，您可能都在使用不同的解析器。谁知道它的数据收集政策是什么呢？

除了在您不知情或未经您同意的情况下收集您的数据并将其出售外，系统还存在更多危险的方式被利用。

欺骗

在欺骗中，DNS 服务器和您之间的路径上的某人会更改响应。欺骗者不会告诉您真实的 IP 地址，而是会为您提供错误的网站 IP 地址。这样，他们就可以阻止您访问真实的网站，或者将您引导到欺诈网站。

同样，这是一种解析器本身可能表现出恶意行为的情况。

例如，假设您正在 Megastore 购物。您想进行价格检查，看看是否可以在竞争对手的在线商店 big-box.com 上以更低的价格买到它。

但是，如果您在 Megastore 的 Wi-Fi 网络上，您可能正在使用他们的解析器。该解析器可能会劫持对 big-box.com 的请求并欺骗您，说该网站不可用。

我们如何通过信任递归解析器 (TRR) 和 DNS over HTTPS (DoH) 来解决这个问题？

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

我们正在引入两个新功能来解决这个问题——信任递归解析器 (TRR) 和 DNS over HTTPS (DoH)。因为实际上，这里存在三个威胁

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

那么我们如何解决这些问题呢？

1. 通过使用信任递归解析器来避免不可信的解析器。
2. 通过使用 DNS over HTTPS 来防止路径上的窃听和篡改。
3. 尽可能少地传输数据，以保护用户免遭匿名化。

通过使用信任递归解析器来避免不可信的解析器

网络可以逃脱提供窃取您的数据或欺骗 DNS 的不可信解析器，因为很少有用户了解风险或如何保护自己。

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

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

Cloudflare 提供了一个递归解析服务，并采用有利于用户隐私的政策。他们承诺在 24 小时后丢弃所有个人身份信息，并且永远不会将这些数据传递给第三方。并且将定期进行审计，以确保数据按预期被清除。

有了它，我们拥有一个可以信任的解析器来保护用户的隐私。这意味着 Firefox 可以忽略网络提供的解析器，直接访问 Cloudflare。有了这个可信的解析器，我们就不必担心恶意解析器出售我们用户的 data 或用欺骗 DNS 欺骗我们的用户。

为什么我们要选择一个解析器？Cloudflare 和我们一样热衷于构建一个以隐私为中心的 DNS 服务。他们与我们合作构建了一个 DoH 解析服务，可以以透明的方式为我们的用户提供良好的服务。他们非常愿意为该服务添加用户保护措施，因此我们很高兴能够与他们合作。

但这并不意味着您必须使用 Cloudflare。用户可以配置 Firefox 使用他们想要的任何支持 DoH 的递归解析器。随着更多产品出现，我们计划让用户更容易发现和切换到它们。

通过使用 DNS over HTTPS 来防止路径上的窃听和篡改

不过，解析器并不是唯一的威胁。路径上的路由器可以跟踪和欺骗 DNS，因为它们可以看到 DNS 请求和响应的内容。但是互联网已经拥有确保路径上的路由器无法以这种方式窃听的技术。这就是我之前提到的加密。

通过使用 HTTPS 交换 DNS 数据包，我们确保没有人可以窥视我们用户发出的 DNS 请求。

尽可能少地传输数据，以保护用户免遭匿名化

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

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

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

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

这样做——删除域名的无关部分并且不包含您的 IP 地址——意味着 DNS 服务器可以收集到的有关您的数据要少得多。

TRR 与 DoH 未能解决的问题是什么？

通过这些修复，我们减少了可以看到您访问哪些网站的人数。但这并不能完全消除数据泄露。

在您进行 DNS 查找以找到 IP 地址之后，您仍然需要连接到该地址上的 Web 服务器。要做到这一点，您需要发送一个初始请求。此请求包含一个服务器名称指示，它指示您要连接到服务器上的哪个站点。并且此请求未加密。

这意味着您的 ISP 仍然可以找出您访问了哪些网站，因为该信息就在服务器名称指示中。此外，将该初始请求从您的浏览器传递到 Web 服务器的路由器也可以看到这些信息。

但是，一旦您建立了与 Web 服务器的连接，那么一切都将被加密。有趣的是，这种加密连接可以用于托管在该服务器上的任何站点，而不仅仅是您最初请求的那个站点。

这有时被称为 HTTP/2 连接合并，或者简称为连接重用。当您打开与支持它的服务器的连接时，该服务器会告诉您它托管的其他网站。然后，您可以使用现有的加密连接访问这些其他网站。

为什么这有帮助？您无需启动新的连接来访问这些其他网站。这意味着您无需发送包含服务器名称指示的未加密的初始请求，该指示表明您要访问哪个网站。这意味着您可以访问同一服务器上的任何其他网站，而无需向您的 ISP 和路径上的路由器透露您正在查看哪些网站。

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

状态如何？

您现在就可以在 Firefox 中启用 DNS over HTTPS，我们 鼓励您这样做.

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

但这是一个重大的改变，我们需要先对其进行测试。因此我们正在进行一项研究。我们要求我们一半的 Firefox Nightly 用户帮助我们收集有关性能的数据。

我们将使用与现在相同的默认解析器，但我们还会将请求发送到 Cloudflare 的 DoH 解析器。然后，我们将比较两者，以确保一切按预期运行。

对于参与研究的参与者，Cloudflare DNS 响应尚未使用。我们只是在检查一切是否正常，然后丢弃 Cloudflare 响应。

我们感谢 Nightly 用户的支持——他们每天帮助我们测试 Firefox——我们希望您也帮助我们测试这一点。