用户面临的隐私和安全隐患与日俱增。 在Mozilla，我们密切关注这些威胁。 我们相信我们有责任尽全力保护Firefox用户及其数据。
一些公司和组织想要秘密收集用户数据并拿来出售。 这就是为什么我们添加了跟踪保护并创建了Facebook容器扩展。 接下来几个月在保护用户数据方面我们会采取更多的措施。
另外两项要添加的保护措施：
- 基于HTTPS的DNS，这是我们倡导的一项新的IETF标准方案
- 可信递归解析器，一种新的解决DNS安全的方案，该方案由我们与Cloudflare合作提供
通过这两项举措，逐渐解决了35年前创建的域名系统中一直存在的数据泄露问题。 我们希望你能帮忙测试这两个方案。 那么来看看如何通过基于HTTPS的DNS和可信递归解析器来保护我们的用户。
但首先，让我们看看网页是如何在互联网中运作的。
如果你对DNS和HTTPS的工作原理已经非常了解，那么可以跳至基于HTTPS的DNS的好处。
什么是HTTP？
当我们解释浏览器如何下载网页时，通常会这样解释：
- 浏览器向服务器发出GET请求。
- 服务器发送一个响应，该响应是一个包含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）。因为目前确实有三个威胁需要解决：
- 可能会使用跟踪你请求的不可信的解析器，或者篡改来自DNS服务器的响应。
- 路径上路由器可以以相同的方式跟踪或篡改。
- DNS服务器可以跟踪你的DNS请求。
如何解决这些问题？
- 使用可信递归解析器避免不可靠的解析器。
- 通过基于HTTPS的DNS防止路径上的窃听和篡改。
- 传输尽可能少的数据，以保护用户免受匿名处理。
使用可信递归解析器避免不可靠的解析器
当网络提供了不可信的解析器来收集你的数据或进行欺骗攻击，网络服务的提供者依然可以全身而退，因为很少有用户知道风险或如何保护自己。
即使对于了解风险的用户，个人用户也很难与他们的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，同时会绘制代码图解。
