图片中的Doh

Internet上的隐私和安全威胁正变得越来越严重。 Mozilla一直在密切关注他们。 我们认为,尽一切可能保护Firefox用户及其数据是我们的责任。

我们担心秘密收集和出售用户数据的公司和组织。 因此,我们添加了跟踪保护并创建了Facebook容器扩展 。 未来几个月将出现更多的保护措施。



现在,我们将另外两种技术添加到列表中:

  • HTTPS DNS是我们参与开发的新IETF标准
  • Trusted Recursive Resolver-与Cloudflare一起提供的一种解决DNS的新安全方法

由于这两项举措,自35年前成立以来一直是域名系统一部分的数据泄漏得到了消除。 我们需要您的帮助进行测试。 让我们看看HTTPS DNS和Trusted Recursive Resolver如何保护我们的用户。

但是首先,让我们看看如何通过Internet传输网页。

如果您已经知道DNS和HTTPS的工作方式,则可以跳到DNS如何通过HTTPS进行帮助的主题。

HTTP短期课程


人们解释浏览器如何加载网页时,通常会这样解释:

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



该系统称为HTTP。

但是这个方案太简单了。 您的浏览器不直接与服务器对话。 可能是因为它们彼此不靠近。

一台服务器可以相距数千公里。 而且您的计算机和服务器之间可能没有直接连接。



因此,在请求从浏览器到达服务器之前,它会经过几手。 答案也是如此。

我认为这是小学生在教室里互相传递笔记的过程。 在外面,便条上写明了送给谁。 写下便条的孩子将其交给邻居。 然后,下一个孩子将其传递给邻居中的一个-可能不是最终接收者,而是正确方向的人。


-Psst ...传给Sandy

问题在于,沿途任何人都可以打开便笺并阅读。 而且,没有办法事先知道票据的去向,因此不知道有哪些人可以使用该票据。

可能会在做有害事情的人的手中...

例如,他们将与所有人共享便笺的内容。


-多汁... 大家好! 丹尼爱上了桑迪!

或更改答案。


“你也喜欢我吗?”
-呵呵,我取笑他,写“不” ...

为了解决这些问题,已经创建了新的HTTP安全版本。 它被称为HTTPS:就像每条消息的锁一样。



只有浏览器和服务器知道要解锁的组合。 即使邮件通过多个路由器,也只有您和网站才能实际读取内容。

这解决了许多安全问题。 但是,浏览器和服务器之间仍然存在未加密的消息。 因此,路上的人仍然可以干涉您的事务。

例如,在连接建立过程中数据仍处于打开状态。 将原始消息发送到服务器时,您还要在“服务器名称指示”字段中发送服务器名称。 这使服务器操作员可以在同一台计算机上运行多个站点,并同时了解您想要联系的人。 此初始请求是加密设置的一部分,但是初始请求本身未加密。

打开数据的另一个地方是DNS。 但是什么是DNS?

DNS:域名系统


在课堂上传递笔记的比喻中,我说过收件人的名字应该写在笔记的外面。 HTTP请求也是如此……它们必须声明要去的地方。

但是您不能使用通常的站点名称。 没有路由器了解您在说谁。 而是使用IP地址。 这就是路由器了解您要将请求发送到哪个服务器的方式。


-请发送至208.80.154.224

这引起了问题。 用户不方便记住IP地址的号码。 我想给这个网站起一个易记的名字...这将被保存在人们的记忆中。

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



浏览器如何解决问题?

一种选择是在浏览器中创建一个大列表,例如电话目录。 但是随着新网站的出现或迁移到新服务器,将很难使该列表保持最新。

因此,有很多彼此链接的小列表,而不是所有域名的单个列表。 这使它们可以独立控制。



要获取与域名对应的IP地址,您需要找到一个包含所需域名的特定列表。 这就像寻找宝藏。

对于像English Wikipedia, en.wikipedia.org这样的网站,这样的寻宝搜索是什么样的?

域可以分为几部分。



通过这些部分,您可以开始寻找包含站点IP地址的列表。 但是我们需要帮助。 代替我们执行此寻线并找到IP地址的工具称为解析器。

首先,解析器访问所谓的根DNS服务器。 他知道几个不同的根DNS服务器,因此他向其中一个发送请求。 解析程序要求根DNS在哪里找到有关.org顶级域区域中地址的其他信息。


-您不知道如何前往en.wikipedia.org?
-我对.org区域一无所知,但5.6.7.8可以提供帮助

下一个服务器称为顶级域名(TLD)服务器。 TLD服务器知道所有以.org结尾的二级域名。

但是,他对wikipedia.org子域一无所知,因此他也不知道en.wikipedia.org的IP地址。

TLD名称服务器将建议解析器向Wikipedia名称服务器询问此问题。


-您不知道如何前往en.wikipedia.org?
-去询问11.21.31.41,他知道wikipedia.org域中的网站

解析器即将完成。 Wikipedia名称服务器是所谓的权威服务器。 他了解wikipedia.org所有子域。 因此,他了解en.wikipedia.org和其他子域,例如de.wikipedia.org的德语版本。 权威服务器告诉解析器可以从哪个IP地址检索该站点的HTML文件。


-您不知道如何前往en.wikipedia.org?
-哦,是的,请转到208.80.154.224

解析程序会将IP地址en.wikipedia.org返回到操作系统。

此过程称为递归解析,因为您必须来回移动,并向不同的服务器询问基本相同的问题。

我说过,我们需要一个解析器来帮助进行搜索。 但是浏览器如何找到该解析器? 通常,他询问操作系统。


“我需要一个解析器。” 你能帮忙吗
-当然,让我向您介绍我使用的解析器

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

可以将计算机配置为使用您信任的特定解析器。 但是很少有人这样做。

而是,最简单地使用默认设置。 默认情况下,操作系统将使用网络上说明的任何解析器。 当计算机连接到网络并接收其IP地址时,网络将建议使用特定的解析器。


-我可以获取IP地址吗?
-没问题! 如果您需要解析器,我建议您使用

这意味着每天可以多次更换所使用的解析器。 如果您白天要去咖啡馆上班,则可能使用的解析器与早晨不同。 即使您设置自己的解析器,也会发生这种情况,因为DNS协议中没有安全性。

如何利用DNS?


那么该系统如何危害用户呢?

通常,解析器会告诉每个DNS服务器您要查找的域。 该请求有时包含您的完整IP地址。 而且,如果地址不完整,那么请求通常会包含您的大部分IP地址,可以轻松地将其与其他信息结合以建立您的身份。


包含您的大多数IP地址...
...以及您要查找的完整域名

这意味着您请求域名解析帮助的每台服务器都会看到您要查找的站点。 此外,前往这些服务器的任何人都可以看到您的请求。

这样的系统通过多种方式来破坏用户数据。 主要的两个是跟踪(tracking)和欺骗(spoofing)。

追踪


如上所述,使用有关IP地址的全部或部分信息来确定请求访问特定站点的人员的身份并不困难。 这意味着DNS服务器和该DNS服务器上的任何用户(途中的路由器)都可以创建用户配置文件。 他们可以列出您查看过的所有站点。

这是有价值的数据。 许多人和公司愿意为浏览您的浏览记录付出很多。


您愿意为有关John Doe所查看信息的信息支付多少费用?

即使我们在此过程中不必担心潜在的臭名昭著的DNS服务器或路由器,仍然存在收集和出售您的数据的风​​险。 因为解析器本身-网络给您的-可能不可靠。

即使您从网络上信任推荐的解析器,也可能只在家里使用它。 正如我所提到的,每次在咖啡馆,酒店或任何其他网络中,您都可能会得到一个不同的解析器。 谁知道他的数据收集政策是什么?

除了在未经您的知情或同意的情况下收集并出售您的数据这一事实之外,该系统还以更加危险的方式使用。

欺骗


通过欺骗,您和DNS服务器之间路径上的某人会更改响应。 欺诈者会告诉您该站点的IP地址错误,而不是真实的IP地址。 因此,他们可能阻止对真实站点的访问或从骗子发送虚假版本。


将其发送到1.6.6.6 ...这是绝对正确的地址,而不是我控制的虚假网站

同样,在这里,解析程序本身可能会声名狼藉。

假设您在Megastore商店购物。 您想比较价格,看看在竞争的在线商店big-box.com中这种产品的价格是否便宜。

但是,如果您在他们的交易室中使用Megastore WiFi,那么您可能会使用他们的解析器。 他可以拦截对big-box.com的请求,并向您撒谎该站点不可用。

如何使用可信递归解析器(TRR)和基于HTTPS的DNS(DoH)解决这种情况?


在Mozilla,我们坚信我们有责任保护用户及其数据,因此我们正在努力解决这些漏洞。

引入了两个新功能来解决此问题:可信递归解析器(TRR)和HTTPS上的DNS(DoH)。 因为实际上存在三种威胁:

  1. 您最终可能会使用不可信的解析器来跟踪您的请求或来自DNS服务器的欺骗响应。
  2. 沿途的路由器可以以相同方式跟踪请求或进行干预。
  3. DNS服务器可以跟踪DNS查询。



如何避免这种情况?

  1. 避免使用TRR不可靠的分解器。
  2. 使用HTTPS上的DNS防止监听和欺骗。
  3. 传输尽可能少的数据,以保护用户免于匿名化。

避免使用TRR不可靠的解析器


网络可能会停止推荐不可靠的解析器来收集用户数据或伪造的DNS查询,因为很少有用户意识到风险或如何保护自己。

即使对于意识到风险的用户,单个用户也很难与他们的提供商或其他组织达成协议,以负责任的方式处理他们的DNS查询。

但是,我们已经研究了这些风险……并且产生了一些影响。 我们一直在寻找可以帮助我们保护用户DNS数据的公司。 他们发现了这样一个: Cloudflare

Cloudflare为用户提供了带有隐私策略的递归解析服务。 他们承诺在24小时后删除所有个人身份数据,并且永远不会将这些数据转让给第三方。 将进行定期检查,以确保按照承诺实际删除了数据。

因此,我们有了一个值得信赖的解析器,可以保护用户的隐私。 这意味着Firefox可以忽略网络解析器,而直接转到Cloudflare。 现在,您不必担心攻击者会使用解析器来出售用户数据或DNS欺骗。

我们为什么选择一个解析器? 像我们一样,Cloudflare也关注创建私有DNS服务。 他们与我们一起开发了一个很好的透明DoH解析器。 该公司很乐意为该服务提供更多保护,因此我们很高兴与他们合作。

但这并不意味着您应该使用Cloudflare。 用户可以将Firefox配置为使用任何启用了DoH的递归解析器。 随着新服务的推出,我们计划实施简单的发现并在它们之间进行切换。

使用HTTPS上的DNS防止侦听和欺骗


但是,解析器并不是唯一的威胁。 途中的路由器可以跟踪和伪造DNS查询,因为它们还可以看到DNS查询和响应的内容。 幸运的是,Internet上已经存在防止在途中听到路由器监听的技术。 这就是我所说的加密。

使用HTTPS交换DNS数据包可保护我们用户的DNS查询免遭间谍活动。

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


除了在DoH协议下运行的受信任解析器之外,Cloudflare和我正在研究其他安全措施。

通常,解析器将完整域名发送到每个服务器:根DNS,顶级域,二级域名服务器等。但是Cloudflare服务器的行为会有所不同。 它只会发送与特定DNS服务器相关的部分。 这称为QNAME最小化


“您不知道如何进入.org服务器?”

通常,解析程序还会在请求中包含IP地址的前24位。 这有助于DNS服务器找出您所在的位置并选择最近的CDN。 但是DNS服务器可以使用此信息将彼此独立的查询链接在一起。

相反,Cloudflare将从其自己的IP地址之一发出请求,该IP地址位于用户旁边。 这提供了地理位置,而无需参考特定的人。 我们还正在探索如何在考虑到隐私的情况下实现更好,更精细的负载平衡。

所有这些操作-删除了域和IP地址的不必要部分-意味着DNS服务器可以收集到的有关您的数据要少得多。



DoH在TRR中遗漏了什么?


这些保护措施减少了可以查看您访问的页面的历史记录的人数。 但是它们不能完全消除数据泄漏。

执行DNS查找后,您仍然需要在该地址连接到Web服务器以获得IP地址。 为此,请发送请求。 该请求包括指示服务器上特定站点的SNI(服务器名称指示)。 并且此请求未加密。

也就是说,您的ISP仍然能够找出您访问的站点,因为它们在SNI中列出。 路由器也会打开信息,这些路由器会将初始请求从浏览器传输到Web服务器。

但是,一旦连接到Web服务器,所有内容都会被加密。 最重要的是,此加密连接可以用于该服务器上的任何站点,而不仅仅是最初请求的站点。

有时将其称为HTTP / 2连接合并或简单地重用连接。 当您打开与兼容服务器的连接时,它将使您知道在其上托管了哪些其他站点。 然后,您可以使用现有的加密连接访问这些站点。

为什么这有用? 因为您无需打开新连接即可连接到这些其他站点。 也就是说,您不需要发送另一个未加密的初始请求,该请求指示SNI以及要访问的站点上的信息公开。 因此,您可以访问同一服务器上的任何其他站点,而无需在整个过程中将它们透露给您的提供商和路由器。

随着CDN的日益普及,单个服务器为越来越多的单个站点提供服务。 而且,由于可以打开多个统一连接,因此可以同时连接到多个共享服务器或CDN,从而访问不同服务器上的所有站点,而不会造成数据泄漏。 因此,此功能越来越有效地用作保护屏幕。

状况如何?


在Firefox中,您可以通过HTTPS启用DNS,我们建议您这样做

我们希望默认情况下为所有用户启用DoH,因为每个人都应享有隐私和安全性,无论他们是否知道DNS泄漏。

但这是一个重大更改,需要首先进行测试。 因此,我们正在进行一项研究。 我们有一半的Firefox Nightly用户要求获得帮助来收集性能数据。

在测试中,使用了现在的默认解析器,但是请求也发送到了Cloudflare DoH解析器。 然后,我们比较结果以验证一切是否按预期进行。

对于研究参与者,尚未使用Cloudflare DNS响应。 我们只是检查一切是否正常,然后抛出Cloudflare响应。



感谢每晚帮助每天测试Firefox的Nightly用户。 我们希望您也能帮助我们。

Source: https://habr.com/ru/post/zh-CN413515/


All Articles