日前,Cloudflare发布了一项用于改善DNS安全和隐私的新的DNS标准ODoH。标准由Cloudflare,Apple和Fastly的工程师共同撰写,标准通过将IP地址与查询分隔开,防止相关信息的泄露。Cloudflare也在Github开源了协议实现和客户端的源代码,可以让大家自己试运行和验证OdoH服务。
![72c1719d92ca36b12b7c93ce9dd94d06.png](https://i-blog.csdnimg.cn/blog_migrate/f2ecd7ffd93d1a95f2e0b4d66c5fd3aa.jpeg)
概述
域名系统(DNS)是人类可以使用的Internet的基础。它将可用的域名(例如cloudflare.com)映射到IP地址以及连接到该域所需的其他信息。在接入网络后设备与DNS解析器之间的网络路径上的任何人都可以看到包含所需主机名(或网站)的查询以及标识设备的IP地址。
为了保护DNS免受旁观者和第三方的侵害,IETF推出了基于HTTPS上的DNS(DoH)和TLS协议DNS(DoT)对DNS传输进行标准化加密。两种协议都可以防止DNS查询在中间过程中被拦截,重定向或篡改。目前很多客户端系统,包括新版本的Firefox,iOS等中都已经实现了对DoT和DoH的支持,但是还未得到全网范围的广泛部署和支持。
基于但是使用对DoT和DoH后目,存在着两个明显的问题:一个是集中化的DNS会引入单点故障。
另一个问题是解析器仍然将所有查询链接到客户端IP地址。
为了解决这个问题, Cloudflare和合作伙伴推出了一个改进的协议,该协议可以实现以下功能:HTTPS Oblivious DNS,或简称ODoH。这些合作伙伴包括PCCW,SURF和Equinix。
![6854b6da2d8ea99cfe99db5c2b8fe2e2.png](https://i-blog.csdnimg.cn/blog_migrate/997c7dc936f7545ad0222ea8269a4a62.jpeg)
OdoH工作原理
ODoH是IETF正在开发的新协议。ODoH通过添加一层公共密钥加密机制以及客户端和DoH服务器之间的网络代理(例如1.1.1.1)来工作。通过两个添加元素的组合确保只有查询用户才能同时访问DNS消息和及其IP地址。
![e5f859f1b6acb76c2497420595269ad0.png](https://i-blog.csdnimg.cn/blog_migrate/88fde3cec4d0f9cfd7b9a653126b666c.jpeg)
OdoH实现中有三个参与者。目标服务器通过代理解密由客户端加密的查询。同样,目标对响应进行加密并将其返回给代理。目标可以是解析器,也可以不是。代理服务器只负责在客户端和目标之间消息转发。客户端行为与在DNS和DoH中的行为相同,但是通过对目标的查询进行加密并解密目标的响应来进行区别。选择这样做的任何客户端都可以指定代理和选择的目标。
增加的添加的加密和机制和代理提供了以下保证:
目标仅可以查看查询和代理的IP地址。
代理无法查看DNS消息,无法识别,读取或修改客户端发送的查询或目标返回的答案。
只有预期的目标才能读取查询的内容并发出响应。
这三个保证在保持DNS查询的安全性和完整性的同时改善了客户端的隐私。但是这些保证中的每一项都依赖于一个基本属性:代理服务器和目标服务器不相互影响。只要两者没有串通,攻击者只有全部拿下代理服务器和目标服务器才能成功。
在该体系架构中目标与执行DNS解析的上游递归解析器是分开的。同样,重要的是,客户可以完全控制代理和目标选择。无需任何类似TRR的程序,客户端除了安全性之外,还可以保留其查询的隐私权。由于目标只和代理联系,目标服务器和任何上游解析程序都不能获得客户端IP地址。这样客户可以更好地控制其查询及其使用方式。例如,客户可以出于任何原因随时选择和更改代理和目标服务器。
ODoH消息流
在ODoH中,"O"表示Oblivious(遗忘),该属性来自DNS消息本身的加密级别。加密是客户端和目标之间的"端到端",并且独立于TLS/HTTPS提供的连接级加密。有人可能会问为什么在存在代理的情况下还需要额外的加密。因为需要两个单独的TLS连接来支持代理功能。具体来说,代理会终止来自客户端的TLS连接,并启动到目标的另一个TLS连接。在这两个连接之间,DNS消息上下文将以纯文本形式显示。为此,ODoH还会在客户端和目标之间加密消息,这样代理无法访问消息内容。
整个过程从客户端使用HPKE加密对目标的查询开始。客户端通过DNS获取目标的公钥,并将其捆绑到HTTPS资源记录中并由DNSSEC保护。当此密钥的TTL过期时,客户端会根据需要请求密钥的新副本(就像A/AAAA记录的TTL过期时一样)。使用目标的DNSSEC验证的公共密钥可确保只有目标目标可以解密查询并加密响应。
客户端通过HTTPS连接将这些加密的查询传输到代理。收到后,代理将查询转发到指定目标。然后目标解密该查询,通过将查询发送到递归解析器(例如1.1.1.1)来生成响应,然后将响应加密到客户端。来自客户端的加密查询包含封装的密钥材料,目标可从中获得响应加密对称密钥。
然后将该响应发送回代理,然后转发给客户端。尽管这些DNS消息是通过两个单独的HTTPS连接(客户端代理和代理目标)传输的,但所有通信都是经过端到端加密的,因此所有通信都经过身份验证和保密。否则在代理中显示为纯文本的消息实际上是加密的乱码。
性能测试
Tranco百万数据集中随机选择了10,000个域,统计了使用不同公钥对A记录的加密及其解密。结果中,99%的代理的DoH查询/响应与其ODoH对应对象之间的额外开销始终小于1毫秒。
但是,ODoH请求:响应管道不仅限于加密。查看度量的一种非常有用的方法是查看累积分布图。下图显示了通过Tor网络传输时DoH,ODoH和DoH中查询/响应时间的累积分布。从左侧开始的水平虚线是50%标记。沿着该水平线,对于任何绘制的曲线,虚线下方的曲线部分为数据点的50%。x轴是时间的度量。左边的线比右边的线变化的快。最后一个重要的细节是x轴以对数刻度绘制,标记的标记之间的距离(10x)在累积分布中相等,但是'x'是指数,代表数量级。因此,尽管前两个标记之间的时间差为9毫秒,但第3个标记和第4个标记之间的时差为900毫秒。
![f0cf03395defa6669c0e7e73bf9745e8.png](https://i-blog.csdnimg.cn/blog_migrate/dee84a4ee8b400344888b36da1afc0f3.jpeg)
在图表中,中间曲线代表ODoH测量值。还测量了隐私保护方案的性能,例如,通过Tor网络传输的DoH查询,如图表中的右曲线所示。与其他面向隐私的DNS变体相比,ODoH将查询时间缩短了一半甚至更好。
在不到228毫秒的时间内,解决ODoH查询的时间占50%。现在,将中间线与代表"直线"(或正常)DoH的左侧线进行比较,而无需进行任何修改。左边的绘图线表示,在50%的时间内,DoH查询在不到146ms的时间内得到解决。从低于50%的标记看,差值的时间永远不会大于100ms。
这些曲线还隐藏了很多信息,因此深入研究测量值很重要。下表具有三个不同的累积分布曲线,这些曲线描述了我们通过代理和目标的延迟来选择ODoH的性能。这也是测量曲线中,其中一些是违反直觉的。例如,0.5之上看,这些曲线表明,无论选择代理和目标,ODOH查询/响应时间的50%实际上是无法区分的。在0.5以下,并将两条实线与代表整体平均值的虚线相比较。该区域表明选择最低延迟代理和目标对平均值的改进很小。最重要的是,其表明选择最低延迟代理会导致性能变差。
![1193aa9d4487a61403f8dda81f4ec72e.png](https://i-blog.csdnimg.cn/blog_migrate/db92333a83d78ff86d776a2c151142c9.jpeg)
OdoH验证
目前Cloudflare已经开源了odoh-rs(Rust)和odoh-go(Golang)中开源了可互
![5ce7b1203408bcd6198d43db644f5fc2.png](https://i-blog.csdnimg.cn/blog_migrate/c9199842a4b54b8d46e56c52f1db7691.jpeg)
操作的OdoH服务器实现,并将目标集成到了Cloudflare DNS解析器中。
还开源了odoh-client-rs( Rust)和odoh-client-go(Golang)客户演示ODoH查询。
1.1.1.1公共DNS中已经支持ODoH查询。可以通过直接查询由OdoH加密的HPKE配置:
![3ff8ac46cb8dc3e504d0cecf7b3b550d.png](https://i-blog.csdnimg.cn/blog_migrate/a43bf97ee7558fd8cd300392229c5ced.jpeg)