Cloudflare OdoH，改善DNS安全和隱私

去年，Cloudflare發(fā)布了一項(xiàng)用于改善DNS安全和隱私的新的DNS標(biāo)準(zhǔn)ODoH。標(biāo)準(zhǔn)由Cloudflare，Apple和Fastly的工程師共同撰寫(xiě)，標(biāo)準(zhǔn)通過(guò)將IP地址與查詢分隔開(kāi)，防止相關(guān)信息的泄露。Cloudflare也在Github開(kāi)源了協(xié)議實(shí)現(xiàn)和客戶端的源代碼，可以讓大家自己試運(yùn)行和驗(yàn)證OdoH服務(wù)。

概述

域名系統(tǒng)（DNS）是人類可以使用的Internet的基礎(chǔ)。它將可用的域名（例如cloudflare.com）映射到IP地址以及連接到該域所需的其他信息。在接入網(wǎng)絡(luò)后設(shè)備與DNS解析器之間的網(wǎng)絡(luò)路徑上的任何人都可以看到包含所需主機(jī)名（或網(wǎng)站）的查詢以及標(biāo)識(shí)設(shè)備的IP地址。

為了保護(hù)DNS免受旁觀者和第三方的侵害，IETF推出了基于HTTPS上的DNS（DoH）和TLS協(xié)議DNS（DoT）對(duì)DNS傳輸進(jìn)行標(biāo)準(zhǔn)化加密。兩種協(xié)議都可以防止DNS查詢?cè)谥虚g過(guò)程中被攔截，重定向或篡改。目前很多客戶端系統(tǒng)，包括新版本的Firefox，iOS等中都已經(jīng)實(shí)現(xiàn)了對(duì)DoT和DoH的支持，但是還未得到全網(wǎng)范圍的廣泛部署和支持。

基于但是使用對(duì)DoT和DoH后目，存在著兩個(gè)明顯的問(wèn)題：一個(gè)是集中化的DNS會(huì)引入單點(diǎn)故障。

另一個(gè)問(wèn)題是解析器仍然將所有查詢鏈接到客戶端IP地址。

為了解決這個(gè)問(wèn)題，Cloudflare和合作伙伴推出了一個(gè)改進(jìn)的協(xié)議，該協(xié)議可以實(shí)現(xiàn)以下功能：HTTPS Oblivious DNS，或簡(jiǎn)稱ODoH。這些合作伙伴包括PCCW，SURF和Equinix。

OdoH工作原理

ODoH是IETF正在開(kāi)發(fā)的新協(xié)議。ODoH通過(guò)添加一層公共密鑰加密機(jī)制以及客戶端和DoH服務(wù)器之間的網(wǎng)絡(luò)代理（例如1.1.1.1）來(lái)工作。通過(guò)兩個(gè)添加元素的組合確保只有查詢用戶才能同時(shí)訪問(wèn)DNS消息和及其IP地址。

OdoH實(shí)現(xiàn)中有三個(gè)參與者。目標(biāo)服務(wù)器通過(guò)代理解密由客戶端加密的查詢。同樣，目標(biāo)對(duì)響應(yīng)進(jìn)行加密并將其返回給代理。目標(biāo)可以是解析器，也可以不是。代理服務(wù)器只負(fù)責(zé)在客戶端和目標(biāo)之間消息轉(zhuǎn)發(fā)?？蛻舳诵袨榕c在DNS和DoH中的行為相同，但是通過(guò)對(duì)目標(biāo)的查詢進(jìn)行加密并解密目標(biāo)的響應(yīng)來(lái)進(jìn)行區(qū)別。選擇這樣做的任何客戶端都可以指定代理和選擇的目標(biāo)。

增加的添加的加密和機(jī)制和代理提供了以下保證：

目標(biāo)僅可以查看查詢和代理的IP地址。

代理無(wú)法查看DNS消息，無(wú)法識(shí)別，讀取或修改客戶端發(fā)送的查詢或目標(biāo)返回的答案。

只有預(yù)期的目標(biāo)才能讀取查詢的內(nèi)容并發(fā)出響應(yīng)。

這三個(gè)保證在保持DNS查詢的安全性和完整性的同時(shí)改善了客戶端的隱私。但是這些保證中的每一項(xiàng)都依賴于一個(gè)基本屬性：代理服務(wù)器和目標(biāo)服務(wù)器不相互影響。只要兩者沒(méi)有串通，攻擊者只有全部拿下代理服務(wù)器和目標(biāo)服務(wù)器才能成功。

在該體系架構(gòu)中目標(biāo)與執(zhí)行DNS解析的上游遞歸解析器是分開(kāi)的。同樣，重要的是，客戶可以完全控制代理和目標(biāo)選擇。無(wú)需任何類似TRR的程序，客戶端除了安全性之外，還可以保留其查詢的隱私權(quán)。由于目標(biāo)只和代理聯(lián)系，目標(biāo)服務(wù)器和任何上游解析程序都不能獲得客戶端IP地址。這樣客戶可以更好地控制其查詢及其使用方式。例如，客戶可以出于任何原因隨時(shí)選擇和更改代理和目標(biāo)服務(wù)器。

ODoH消息流

在ODoH中，"O"表示Oblivious（遺忘），該屬性來(lái)自DNS消息本身的加密級(jí)別。加密是客戶端和目標(biāo)之間的"端到端"，并且獨(dú)立于TLS/HTTPS提供的連接級(jí)加密。有人可能會(huì)問(wèn)為什么在存在代理的情況下還需要額外的加密。因?yàn)樾枰獌蓚€(gè)單獨(dú)的TLS連接來(lái)支持代理功能。具體來(lái)說(shuō)，代理會(huì)終止來(lái)自客戶端的TLS連接，并啟動(dòng)到目標(biāo)的另一個(gè)TLS連接。在這兩個(gè)連接之間，DNS消息上下文將以純文本形式顯示。為此，ODoH還會(huì)在客戶端和目標(biāo)之間加密消息，這樣代理無(wú)法訪問(wèn)消息內(nèi)容。

整個(gè)過(guò)程從客戶端使用HPKE加密對(duì)目標(biāo)的查詢開(kāi)始?？蛻舳送ㄟ^(guò)DNS獲取目標(biāo)的公鑰，并將其捆綁到HTTPS資源記錄中并由DNSSEC保護(hù)。當(dāng)此密鑰的TTL過(guò)期時(shí)，客戶端會(huì)根據(jù)需要請(qǐng)求密鑰的新副本（就像A/AAAA記錄的TTL過(guò)期時(shí)一樣）。使用目標(biāo)的DNSSEC驗(yàn)證的公共密鑰可確保只有目標(biāo)目標(biāo)可以解密查詢并加密響應(yīng)。

客戶端通過(guò)HTTPS連接將這些加密的查詢傳輸?shù)酱怼Ｊ盏胶?，代理將查詢轉(zhuǎn)發(fā)到指定目標(biāo)。然后目標(biāo)解密該查詢，通過(guò)將查詢發(fā)送到遞歸解析器（例如1.1.1.1）來(lái)生成響應(yīng)，然后將響應(yīng)加密到客戶端。來(lái)自客戶端的加密查詢包含封裝的密鑰材料，目標(biāo)可從中獲得響應(yīng)加密對(duì)稱密鑰。

然后將該響應(yīng)發(fā)送回代理，然后轉(zhuǎn)發(fā)給客戶端。盡管這些DNS消息是通過(guò)兩個(gè)單獨(dú)的HTTPS連接（客戶端代理和代理目標(biāo)）傳輸?shù)模型ㄐ哦际墙?jīng)過(guò)端到端加密的，因此所有通信都經(jīng)過(guò)身份驗(yàn)證和保密。否則在代理中顯示為純文本的消息實(shí)際上是加密的亂碼。

性能測(cè)試

Tranco百萬(wàn)數(shù)據(jù)集中隨機(jī)選擇了10,000個(gè)域，統(tǒng)計(jì)了使用不同公鑰對(duì)A記錄的加密及其解密。結(jié)果中，99%的代理的DoH查詢/響應(yīng)與其ODoH對(duì)應(yīng)對(duì)象之間的額外開(kāi)銷始終小于1毫秒。

但是，ODoH請(qǐng)求：響應(yīng)管道不僅限于加密。查看度量的一種非常有用的方法是查看累積分布圖。下圖顯示了通過(guò)Tor網(wǎng)絡(luò)傳輸時(shí)DoH，ODoH和DoH中查詢/響應(yīng)時(shí)間的累積分布。從左側(cè)開(kāi)始的水平虛線是50%標(biāo)記。沿著該水平線，對(duì)于任何繪制的曲線，虛線下方的曲線部分為數(shù)據(jù)點(diǎn)的50%。x軸是時(shí)間的度量。左邊的線比右邊的線變化的快。最后一個(gè)重要的細(xì)節(jié)是x軸以對(duì)數(shù)刻度繪制，標(biāo)記的標(biāo)記之間的距離（10x）在累積分布中相等，但是'x'是指數(shù)，代表數(shù)量級(jí)。因此，盡管前兩個(gè)標(biāo)記之間的時(shí)間差為9毫秒，但第3個(gè)標(biāo)記和第4個(gè)標(biāo)記之間的時(shí)差為900毫秒。

在圖表中，中間曲線代表ODoH測(cè)量值。還測(cè)量了隱私保護(hù)方案的性能，例如，通過(guò)Tor網(wǎng)絡(luò)傳輸?shù)腄oH查詢，如圖表中的右曲線所示。與其他面向隱私的DNS變體相比，ODoH將查詢時(shí)間縮短了一半甚至更好。

在不到228毫秒的時(shí)間內(nèi)，解決ODoH查詢的時(shí)間占50%?，F(xiàn)在，將中間線與代表"直線"（或正常）DoH的左側(cè)線進(jìn)行比較，而無(wú)需進(jìn)行任何修改。左邊的繪圖線表示，在50%的時(shí)間內(nèi)，DoH查詢?cè)诓坏?46ms的時(shí)間內(nèi)得到解決。從低于50%的標(biāo)記看，差值的時(shí)間永遠(yuǎn)不會(huì)大于100ms。

這些曲線還隱藏了很多信息，因此深入研究測(cè)量值很重要。下表具有三個(gè)不同的累積分布曲線，這些曲線描述了我們通過(guò)代理和目標(biāo)的延遲來(lái)選擇ODoH的性能。這也是測(cè)量曲線中，其中一些是違反直覺(jué)的。例如，0.5之上看，這些曲線表明，無(wú)論選擇代理和目標(biāo)，ODOH查詢/響應(yīng)時(shí)間的50%實(shí)際上是無(wú)法區(qū)分的。在0.5以下，并將兩條實(shí)線與代表整體平均值的虛線相比較。該區(qū)域表明選擇最低延遲代理和目標(biāo)對(duì)平均值的改進(jìn)很小。最重要的是，其表明選擇最低延遲代理會(huì)導(dǎo)致性能變差。

OdoH驗(yàn)證

目前Cloudflare已經(jīng)開(kāi)源了odoh-rs（Rust）和odoh-go（Golang）中開(kāi)源了可互

操作的OdoH服務(wù)器實(shí)現(xiàn)，并將目標(biāo)集成到了Cloudflare DNS解析器中。

還開(kāi)源了odoh-client-rs（Rust）和odoh-client-go（Golang）客戶演示ODoH查詢。

1.1.1.1公共DNS中已經(jīng)支持ODoH查詢?？梢酝ㄟ^(guò)直接查詢由OdoH加密的HPKE配置：