DNS加密說明,dns加密-ESG跨境

DNS加密說明,dns加密

DNS加密說明

域名系統(tǒng)（DNS）是互聯(lián)網(wǎng)的地址簿。當(dāng)您訪問cloudflare.com或任何其他站點時，您的瀏覽器將向DNS解析器詢問可以找到站點的IP地址。不幸的是，這些DNS查詢和回應(yīng)通常是不受保護(hù)的。加密DNS將改善用戶隱私和安全性。在本文中，我們將研究兩種用于加密DNS的機制，稱為DNS over TLS（DoT）以及DNS over HTTPS（DoH），并解釋它們的工作原理。

希望將域名解析為IP地址的應(yīng)用程序通常都會用到DNS。通常，編寫應(yīng)用程序的程序員不會明確地做到這一點。取而代之的是，程序員編寫如fetch(https://example.com/news)的代碼，并期望軟件庫能夠處理“example.com”到IP地址的轉(zhuǎn)換。

在后臺，軟件庫負(fù)責(zé)發(fā)現(xiàn)并連接到外部遞歸DNS解析器，使用DNS協(xié)議(見下圖)解析應(yīng)用程序請求的名稱。外部DNS解析器的選擇以及是否提供任何隱私性和安全性都不在應(yīng)用程序的控制范圍內(nèi)。它取決于所使用的軟件庫，以及運行該軟件的設(shè)備的操作系統(tǒng)所提供的策略。

外部DNS解析器

操作系統(tǒng)通常使用動態(tài)主機配置協(xié)議(DHCP)從本地網(wǎng)絡(luò)學(xué)習(xí)解析器地址。在家庭和移動網(wǎng)絡(luò)中，它通常使用來自互聯(lián)網(wǎng)服務(wù)提供商（ISP）的解析器。在公司網(wǎng)絡(luò)中，所選的解析器通常由網(wǎng)絡(luò)管理員控制。如有所需，可控制自己設(shè)備的用戶可以使用特定地址來覆蓋解析器，例如Google的8.8.8.8或Cloudflare的1.1.1.1之類的公共解析器的地址，但大多數(shù)用戶在連接咖啡店或機場的公共WiFi熱點時，可能不會費心去更換它。

外部解析器的選擇直接影響最終用戶的體驗。大多數(shù)用戶不會更改其解析器設(shè)置，并且很可能最終會使用其網(wǎng)絡(luò)提供商提供的DNS解析器。最明顯的可觀察屬性是名稱解析的速度和準(zhǔn)確性。改善隱私性或安全性的功能可能不會立即見效，但將有助于防止其他人分析或干擾您的瀏覽活動。這在公共WiFi網(wǎng)絡(luò)上尤其重要，在公共WiFi網(wǎng)絡(luò)上，任何物理上接近的人都可以捕獲和解密無線網(wǎng)絡(luò)流量。

未加密的DNS

自從1987年DNS誕生以來，它就一直處于未加密狀態(tài)。您的設(shè)備與解析器之間的每個人都可以監(jiān)聽甚至修改您的DNS查詢和響應(yīng)。這包括您本地WiFi網(wǎng)絡(luò)中的任何人，您的互聯(lián)網(wǎng)服務(wù)提供商（ISP）和傳輸提供商。這可能會披露您訪問的域名從而威脅您的隱私。

他們能看到什么？那么，來看一下從連接到家庭網(wǎng)絡(luò)的筆記本上截取的網(wǎng)絡(luò)數(shù)據(jù)包吧：

我們可以觀察到以下幾點：

UDP源端口是53，這是未加密DNS的標(biāo)準(zhǔn)端口號。因此，UDP有效負(fù)載很可能是一個DNS響應(yīng)。

這表明源IP地址192.168.2.254是DNS解析器，而目標(biāo)IP 192.168.2.14是DNS客戶端。

UDP有效負(fù)載確實可以解析為DNS響應(yīng)，并顯示用戶正試圖訪問twitter.com。

如果將來有連接到104.244.42.129或104.244.42.1的連接，那么很可能是指向“twitter.com”的流量。

如果此IP上有進(jìn)一步加密的HTTPS流量，接下來會有更多DNS查詢，這可能表明web瀏覽器從該頁面加載了額外的資源。這可能會泄露用戶訪問twitter.com時正在查看的頁面。

由于DNS消息不受保護(hù)，因此可能會發(fā)生其他攻擊：

查詢可以定向到執(zhí)行DNS劫持的解析器。例如，在英國，Virgin Media和BT對不存在的域返回假響應(yīng)，從而將用戶重定向到搜索頁面。這種重定向是可能的，因為計算機/電話盲目地信任由ISP提供的網(wǎng)關(guān)路由器使用DHCP通告的DNS解析器。

防火墻可以很容易地攔截、阻止或修改任何基于端口號的未加密DNS流量。值得注意的是，明文檢查并不是訪問可見性目標(biāo)的靈丹妙藥，因為DNS解析器是可以被繞過的。

加密DNS

對DNS進(jìn)行加密會使網(wǎng)絡(luò)窺探者更難以查看您的DNS信息，或在傳輸過程中破壞它們。就像網(wǎng)絡(luò)從未加密的HTTP遷移到加密的HTTPS一樣，現(xiàn)在也有對DNS本身加密的DNS協(xié)議的升級。加密網(wǎng)絡(luò)使私人和安全的通信與商業(yè)得以蓬勃發(fā)展。加密DNS將進(jìn)一步增強用戶隱私性。

存在兩種標(biāo)準(zhǔn)化的機制來保護(hù)您和解析器之間的DNS傳輸，即DNS over TLS(2016)和DNS Queries over HTTPS(2018)。兩者都基于傳輸層安全性（TLS），TLS也用于保護(hù)您與使用HTTPS的網(wǎng)站之間的通信。在TLS中，服務(wù)器（無論是web服務(wù)器還是DNS解析器）使用證書向客戶端（您的設(shè)備）進(jìn)行身份驗證。

通過DNS over TLS（DoT），原始的DNS消息被直接嵌入到安全的TLS通道中。從外面看，他人既無法了解正在查詢的名稱，也無法對其進(jìn)行修改。預(yù)期中的客戶端應(yīng)用程序?qū)⒛軌蚪饷躎LS，如下所示：

在對未加密DNS包的跟蹤中，很明顯，客戶端可以直接發(fā)快遞一個DNS請求，然后解析器給出一個DNS響應(yīng)。然而，在加密的DoT情況下，在發(fā)快遞加密DNS消息之前客戶端與服務(wù)器會交換一些TLS握手消息：

客戶端發(fā)快遞一個Client Hello，通告其支持TLS功能。

服務(wù)器以服務(wù)器Hello響應(yīng)，并同意將用于保護(hù)連接的TLS參數(shù)。證書消息包含服務(wù)器的身份，而證書驗證消息將包含數(shù)字簽名，客戶端可以使用服務(wù)器證書對其進(jìn)行驗證?？蛻舳送ǔ鶕?jù)其本地受信任的證書頒發(fā)機構(gòu)列表來檢查此證書，但是DoT規(guī)范提到了其他信任機制，例如公鑰固定。

客戶端和服務(wù)器都完成TLS握手后，它們終于可以開始交換加密的消息。

雖然上面的圖片僅包含一個DNS查詢和響應(yīng)，但在實踐中，安全TLS連接將保持開放，并將被重新用于以后的DNS查詢。

此前已實現(xiàn)通過新端口上非常快的TLS來保護(hù)未加密協(xié)議：

網(wǎng)絡(luò)流量：HTTP(tcp/80)gt;HTTPS(tcp/443)

發(fā)快遞電子郵件：SMTP(tcp/25)gt;SMTPS(tcp/465)

接收電子郵件：IMAP(tcp/143)gt;IMAPS(tcp/993)

現(xiàn)在：DNS(tcp/53 or udp/53)gt;DoT(tcp/853)

引入新端口的一個問題是現(xiàn)有的防火墻可能會阻止它。因為它們采用了必須明確啟用新服務(wù)的白名單方法，或者因為采用了網(wǎng)絡(luò)管理員明確禁止服務(wù)的阻止列表方法。如果安全選項（DoT）比不安全選項的可用性更低，那么用戶和應(yīng)用程序可能會試圖退回到未加密的DNS。這隨后可能允許攻擊者強制用戶使用不安全的版本。

這種回退攻擊不是僅存于理論上的。SSL剝離此前曾被用于將HTTPS網(wǎng)站降級為HTTP，從而允許攻擊者竊取密碼或劫持賬戶。

另一種方法，NS Queries over HTTPS（DoH），旨在支持兩個主要用例：

防止路徑上的設(shè)備干擾DNS的上述問題。這包括上面的端口阻塞問題。

允許web應(yīng)用程序通過現(xiàn)有的瀏覽器API訪問DNS。

DoH本質(zhì)上是HTTPS，與web使用的加密標(biāo)準(zhǔn)相同，并且重用相同的端口號（tcp/443）。Web瀏覽器已經(jīng)不支持不安全的HTTP，而支持HTTPS。這使得HTTPS成為安全傳輸DNS消息的最佳選擇。您可以在這里找到此類DoH的請求示例。

DoH：通過安全的HTTPS流傳輸DNS查詢和響應(yīng)

一些用戶擔(dān)心HTTPS的使用可能會削弱隱私性，因為cookie可能會被用于跟蹤目的。DoH協(xié)議設(shè)計者考慮了各種隱私方面的問題，并明確建議不要使用HTTP cookie以防止跟蹤，這一建議已得到廣泛遵循。TLS會話恢復(fù)可提高TLS 1.2握手性能，但可以被潛在地用于關(guān)聯(lián)TLS連接。幸運的是，使用TLS 1.3可以通過默認(rèn)情況下減少往返次數(shù)來消除TLS會話恢復(fù)的需要，從而有效地解決了與之相關(guān)的隱私問題。

使用HTTPS意味著HTTP協(xié)議的改進(jìn)也可以使DoH受益。例如，基于QUIC的正處于開發(fā)之中的HTTP/3協(xié)議可以提供額外的性能改進(jìn)，以解決由于缺少前端阻塞而導(dǎo)致的數(shù)據(jù)包丟失。這意味著當(dāng)一個數(shù)據(jù)包丟失時，我們可以通過安全通道同時發(fā)快遞多個DNS查詢，而不會互相阻塞。

還有一個基于DNS over QUIC（DNS/QUIC）的草案，類似DoT，但是由于使用了QUIC，因此沒有前端阻塞問題。然而，HTTP/3和DNS/QUIC都需要一個UDP端口才能訪問。理論上，兩者都可以分別通過HTTP/2和DoT退回到DoH。

部署DoT和DoH

由于DoT和DoH都是相對較新的技術(shù)，它們還沒有得到普遍應(yīng)用。在服務(wù)器端，主要的公共解析器包括Cloudflare的1.1.1.1和谷歌DNS都支持它。然而，許多ISP解決方案仍然缺乏對它的支持。您可以在DNS服務(wù)器源上找到支持DoH的一小部分公共解析器，還可以在DNS隱私公共解析器上找到另一種支持DoT和DoH的公共解析器。

有兩種方法可在最終用戶設(shè)備上啟用DoT或DoH：

添加對應(yīng)用程序的支持，繞過來自操作系統(tǒng)的解析器服務(wù)。

添加對操作系統(tǒng)的支持，透明地為應(yīng)用程序提供支持。

在客戶端，DoT或DoH通常有三種配置模式：

關(guān)閉：DNS將不會被加密。

機會模式：嘗試為DNS使用安全傳輸，但如果前者不可用，則退回到未加密的DNS。這種模式容易受到降級攻擊，攻擊者可以迫使設(shè)備使用未加密的DNS。機會模式的目的是在沒有活躍的攻擊者時提供隱私性。

嚴(yán)格模式：嘗試通過安全傳輸使用DNS。如果不可用，則出現(xiàn)嚴(yán)重故障并向用戶顯示錯誤。

通過安全傳輸進(jìn)行DNS的系統(tǒng)范圍配置的當(dāng)前狀態(tài)：

Android 9：通過其“私有DNS”功能支持DoT。模式：

默認(rèn)情況下使用機會模式（“自動”）。將使用網(wǎng)絡(luò)設(shè)置（通常為DHCP）中的解析器。

可以通過設(shè)置明確的主機名來配置嚴(yán)格模式。不允許使用IP地址，使用默認(rèn)解析器解析主機名，該主機名還用于驗證證書。（相關(guān)源代碼）

iOS和Android用戶還可以安裝1.1.1.1應(yīng)用程序從而在嚴(yán)格模式下啟用DoH或DoT支持。在內(nèi)部，它使用VPN編程接口來啟用對未加密DNS流量的攔截，然后再通過安全通道轉(zhuǎn)發(fā)。

通過systemd 239解析的linux：通過DNSOverTLS選項啟用DoT。

默認(rèn)為關(guān)閉。

可以配置機會模式，但不執(zhí)行證書驗證。

從systemd 243開始提供嚴(yán)格模式。接受由受信任的證書頒發(fā)機構(gòu)簽署的任何證書。但是，GnuTLS后端沒有主機名驗證，而OpenSSL后端需要一個IP地址。

在任何情況下，都不會發(fā)快遞服務(wù)器名稱指示（SNI）。證書名稱沒有經(jīng)過驗證，這使得中間人變得微不足道。

linux、macOS和Windows可以在嚴(yán)格模式下使用DoH客戶端。cloudflared proxydns命令默認(rèn)情況下使用Cloudflare DNS解析器，但用戶可以通過proxydnsupstream選項覆蓋它。

Web瀏覽器支持DoH而非DoT：

Firefox 62支持DoH，并提供了幾種可信遞歸解析器（TRR）設(shè)置。默認(rèn)情況下，DoH處于禁用狀態(tài)，但是Mozilla正在進(jìn)行一項實驗，為美國的一些用戶啟用DoH。這個實驗?zāi)壳笆褂玫氖荂loudflare的1.1.1.1解析器，因為我們是目前唯一滿足Mozilla所要求的嚴(yán)格解析器策略的提供商。由于許多DNS解析器仍然不支持加密的DNS傳輸，Mozilla的方法將確保使用DoH保護(hù)更多用戶。

當(dāng)通過實驗或網(wǎng)絡(luò)設(shè)置中的“通過HTTPS啟用DNS”選項啟用時，F(xiàn)irefox將使用機會模式（network.trr.mode=2 at about:config）。

可以使用network.trr.mode=3啟用嚴(yán)格模式，但是需要指定一個明確的解析器IP（例如，network.trr.bootstrapAddress=1.1.1.1）。

盡管Firefox會忽略系統(tǒng)中的默認(rèn)解析器，但可以使用其他解析器進(jìn)行配置。此外，使用不支持DoH解析器的企業(yè)部署可以選擇禁用DoH。

如果系統(tǒng)解析器地址與硬編碼的DoH提供者之一（源代碼更改）匹配，Chrome 78就會啟用機會DoH。除Linux和iOS之外，所有平臺均啟用了此實驗，并且默認(rèn)情況下不包括企業(yè)部署。

Opera 65添加了一個選項，來通過Cloudflare的1.1.1.1解析器啟用DoH。默認(rèn)情況下，此功能是關(guān)閉的。啟用后，它似乎會使用機會模式：如果1.1.1.1:443（無SNI）可訪問，它將被使用。否則，它會退回到默認(rèn)的解析器（未加密）。

curl項目中的DNS over HTTPS頁面擁有一個DoH提供程序和其他實現(xiàn)的完整列表。

除了加密設(shè)備和外部DNS解析器之間的整個網(wǎng)絡(luò)路徑之外，還可以采取一種折衷的方法：在設(shè)備和本地網(wǎng)絡(luò)的網(wǎng)關(guān)之間使用未加密的DNS，但是對網(wǎng)關(guān)路由器與外部DNS解析器之間的所有DNS通信進(jìn)行加密。假設(shè)有一個安全的有線或無線網(wǎng)絡(luò)，這將保護(hù)本地網(wǎng)絡(luò)中的所有設(shè)備不受ISP監(jiān)視或互聯(lián)網(wǎng)上其他對手的攻擊。由于公共WiFi熱點被認(rèn)為是不安全的，這種方法在開放WiFi網(wǎng)絡(luò)上也不安全。即使它有WPA2PSK的密碼保護(hù)，其他人仍然能夠窺探和修改未加密的DNS。

其他安全注意事項

前面幾節(jié)描述了安全DNS傳輸、DoH和DoT。這些只能確保您的客戶端從DNS解析器收到未經(jīng)篡改的應(yīng)答。但是，它不能保護(hù)客戶端不受解析器返回錯誤應(yīng)答的影響（通過DNS劫持或DNS緩存中毒攻擊）。“真實”答案由權(quán)威名稱服務(wù)器報告的域或區(qū)域的所有者決定。DNSSEC允許客戶端驗證返回的DNS答案的完整性，并捕獲客戶端與權(quán)威名稱服務(wù)器之間路徑上的任何未經(jīng)授權(quán)的篡改。

但是，錯誤轉(zhuǎn)發(fā)DNS消息的中間盒阻礙了DNSSEC的部署，而且即使信息可用，應(yīng)用程序使用的存根解析器也可能無法驗證結(jié)果。2016年的一份報告發(fā)現(xiàn)，只有26%的用戶使用DNSSEC驗證解析器。

DoH和DoT保護(hù)客戶端和公共解析器之間的傳輸。公共解析器可能必須與其他權(quán)威名稱服務(wù)器聯(lián)系才能解析名稱。傳統(tǒng)上，任何解析器和權(quán)威名稱服務(wù)器之間的路徑都使用未加密的DNS。為了保護(hù)這些DNS消息，我們對Facebook進(jìn)行了實驗，在1.1.1.1和Facebook的權(quán)威名稱服務(wù)器之間使用DoT。雖然使用TLS設(shè)置安全通道會增加延遲，但它可以分?jǐn)偟皆S多查詢中。

傳輸加密可確保解析器結(jié)果和元數(shù)據(jù)受到保護(hù)。例如，DNS查詢中包含的EDNS客戶端子網(wǎng)（ECS）信息可以顯示啟動DNS查詢的原始客戶端地址。沿路徑隱藏這些信息可以提高隱私性。它還可以防止由于轉(zhuǎn)發(fā)DNS中的問題而導(dǎo)致?lián)p壞的中間盒破壞DNSSEC。

DNS加密的操作問題

DNS加密可能會給依賴于監(jiān)視或修改DNS流量的個人或組織帶來挑戰(zhàn)。依賴被動監(jiān)視的安全設(shè)備監(jiān)視著計算機或網(wǎng)絡(luò)邊緣上的所有傳入和傳出網(wǎng)絡(luò)流量。例如，基于未加密的DNS查詢，他們可能識別出被惡意軟件感染的機器。如果對DNS查詢進(jìn)行了加密，那么被動監(jiān)視解決方案將無法監(jiān)視域名。

某些團(tuán)體期望DNS解析器出于以下目的而應(yīng)用內(nèi)容過濾：

阻止用于分發(fā)惡意軟件的域。

屏蔽廣告。

執(zhí)行家長控制過濾，阻止與成人內(nèi)容相關(guān)的域。

根據(jù)當(dāng)?shù)胤ㄒ?guī)禁止訪問提供非法內(nèi)容的域。

提供一個拆分域DNS，根據(jù)源網(wǎng)絡(luò)提供不同的回應(yīng)。

阻止通過DNS解析器訪問域的一個優(yōu)點是它可以被集中完成，而不需要在每個應(yīng)用程序中重新實現(xiàn)它。不幸的是，它也相當(dāng)粗糙。假設(shè)一個網(wǎng)站在example.com/videos/forkids/和example.com/videos/foradults/為多個用戶托管內(nèi)容。DNS解析器將只能看到“example.com”，并可以選擇是否阻止它。在這種情況下，特定于應(yīng)用程序的控件（如瀏覽器擴展）將更有效，因為它們可以實際查看url并有選擇地阻止訪問內(nèi)容。

DNS監(jiān)控并不全面。惡意軟件可能會跳過DNS和硬編碼IP地址，或使用其他方法來查詢IP地址。但是，并非所有惡意軟件都這么復(fù)雜，因此DNS監(jiān)控仍可以充當(dāng)深度防御工具。

所有這些非被動監(jiān)視或DNS阻塞用例都需要DNS解析器的支持。依賴于當(dāng)前解析器的DoH/DoT機會式升級的部署將保持未加密DNS上通常提供的相同特性集。不幸的是，正如前面提到的，這很容易被降級。為了解決這個問題，系統(tǒng)管理員可以將端點指向嚴(yán)格模式下的DoH/DoT解析器。理想情況下，這可以通過安全的設(shè)備管理解決方案（MDM，Windows上的組策略等）來實現(xiàn)。

結(jié)論

互聯(lián)網(wǎng)的基石之一是使用DNS將名稱映射到地址。DNS傳統(tǒng)上使用不安全，未加密的傳輸。過去，這已被ISP濫用于廣告注入，但也導(dǎo)致了隱私泄漏。咖啡店里的安管閑事的顧客可以使用未加密的DNS來跟蹤您的活動。所有這些問題都可以通過使用DNS over TLS（DoT）或DNS over HTTPS（DoH）來解決。這些保護(hù)用戶的技術(shù)相對較新，而且正在被越來越多的人采用。

從技術(shù)角度來看，DoH與HTTPS非常相似，并且遵循行業(yè)普遍趨勢來棄用非安全選項。與DoH相比，DoT是一種更簡單的傳輸模式，因為它除去了HTTP層，但是這也使得它更容易被阻塞，不管是故意的還是意外的。

選擇安全的DNS解析器是啟用安全傳輸?shù)牡诙獎?wù)。一些供應(yīng)商會使用本地配置的DNS解析器，但會嘗試將未加密的傳輸升級為更安全的傳輸（DoT或DoH）。不幸的是，DNS解析器通常默認(rèn)由ISP提供，而ISP可能不支持安全傳輸。

Mozilla采取了不同的方法。它們允許用戶明確地選擇一個解析器，而不是依賴于甚至可能不支持DoH的本地解析器。Mozilla推薦的解析器必須滿足高標(biāo)準(zhǔn)，以保護(hù)用戶隱私。為了確保基于DNS的家長控制功能繼續(xù)發(fā)揮作用，并支持分割域用例，Mozilla添加了一種機制，該機制允許私有解析器禁用DoH。

DoT和DoH傳輸協(xié)議已經(jīng)為我們轉(zhuǎn)移到更安全的互聯(lián)網(wǎng)做好了準(zhǔn)備。從前面的數(shù)據(jù)包跟蹤中可以看出，這些協(xié)議類似于現(xiàn)有的保護(hù)應(yīng)用程序通信流的機制。當(dāng)這個安全和隱私漏洞被關(guān)閉后，將來還會有更多的問題需要解決。

特別聲明：以上文章內(nèi)容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關(guān)于作品內(nèi)容、版權(quán)或其它問題請于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。