保持加密，保持安全：使用 ESNI、DoH 和 DoT

保護互聯網隱私的最新進展包括加密的 TLS 服務器名稱指示 (ESNI) 和 DNS over HTTPS (DoH) 形式的加密 DNS，這兩者都被數據收集者認為是極具爭議的。

因此，這裡快速瀏覽一下它們存在的原因、它們的詳細信息以及它們工作方式背後的技術。

DNS 需要正常運行

拆分隧道虛擬專用網絡 (VPN) 連接、Web 代理自動發現 (WPAD) 協議、零配置多播 DNS (mDNS)、實時黑名單 (RBL) 以及許多其他廣泛部署的技術在 DNS 不中斷時會中斷” t 正確操作。

為了利益和名譽而破壞互聯網

早在 2003 年，互聯網用戶就了解到 DNS 在全球範圍內的重要性，當時運營.com頂級域 (TLD) 的公司選擇停止發布NXDOMAIN響應。 相反，他們冒充任何不存在的域，試圖提供更多廣告、銷售更多域並最終產生更多收入。 意料之外的連鎖反應引發了一場公開辯論，並引發了 ICANN 安全與穩定諮詢委員會 (SSAC) 的一份譴責報告。 該項目確實已關閉，但從技術角度來看，該漏洞仍然存在。

2008 年晚些時候，當一些最大的 ISP 最終引入了針對幾乎任何網站的跨站點腳本攻擊的各種途徑時，再次公開呼籲操縱 DNS 以獲取利潤的嘗試。 由於漏洞的性質，即使是託管在專用網絡上且無法從 Internet 訪問的網站也可以被利用。

發現的問題不在於核心互聯網協議，而是由於某些 DNS 功能的不當貨幣化而加劇的問題。

Paul Vixie，互聯網系統聯盟 (ISC)

雖然協議本身確實不是問題的真正原因，但這些協議也確實不能防止不良行為者濫用系統。 因此，從技術角度來看，該漏洞仍然存在。

打破互聯網進行監視和審查

2016 年，觀察到伊朗的 ISP 正在操縱 DNS。 這一次，他們沒有註入廣告，而是阻止了對 Internet 上前 10,000 個域中的 139 個的電子郵件服務器的訪問。 目前尚不清楚這是否是針對這些特定域的故意拒絕服務政策（類似於中國舉世聞名的審查制度），或者可能只是攔截 DNS 查詢的任何系統的不良技術實施示例。

不知道 DNS 被攔截的原因很重要：即使我們拋開有關全面監視和審查的道德和法律問題，用於執行此操作的技術本質上是不符合標準的，很可能會干擾您對互聯網的正常、日常、合理和合法使用。

然而，從技術角度來看，該漏洞仍然存在。

出於邪惡目的破壞互聯網

當然，不只是商業實體和政府試圖以自己的方式攔截互聯網流量。 有很多犯罪分子試圖劫持連接的例子，通常是為了竊取用戶數據或誘騙用戶洩露重要的訪問憑據。 最突出的是，DNS 緩存中毒已被用於將用戶引導至網絡釣魚站點、部署勒索軟件、部署殭屍網絡、拒絕向特定網站提供服務等等。

TLS 洩漏誰連接到誰

傳輸層安全 (TLS) 是 HTTPS 背後的技術，HTTPS 是我們每天都依賴的安全版本的 HTTP。 建立 TLS 連接需要多個步驟，在此期間服務器通過出示證書證明其身份，並交換新的加密密鑰。

讓服務器使用證書來證明其身份是非常重要的一步，因為證書的一部分是非對稱公共加密密鑰。

當客戶端使用此密鑰發送消息時，只有擁有相關私鑰的服務器才能讀取該消息。 結果，任何攔截或監聽連接的人都被鎖定並且無法閱讀內容。

但是，初始交換仍然是在沒有加密的情況下以明文方式進行的，這意味著觀察者將始終知道服務器的身份。

領域前沿

一些反審查類型的工具使用稱為域前端的技術在一段時間內解決了 TLS 中的這種洩漏問題。 這利用了這樣一個事實，即一旦建立了 HTTPS 連接，大多數大型託管服務提供商不會檢查每個 HTTP 請求中顯示的主機名是否與 TLS 握手中使用的主機名匹配。 在隱私工具方面，這被視為一個有用的功能，允許與隱藏站點進行秘密通信。 對於託管服務提供商和數據收集者來說，這被視為對規範實施方式的濫用。

這本身就是一個漏洞，因此已由包括 AWS 在內的幾家主要託管服務提供商修復。

通過更改標準解決問題：加密 SNI (ESNI)

ESNI 背後的想法是通過加密所有消息（包括初始Client Hello消息）來防止 TLS 洩漏任何數據。 這讓任何觀察者都完全不知道服務器提供的是什麼服務器證書。

為此，客戶端在建立連接之前需要一個加密密鑰。 因此，ESNI 要求將一組特定的 ESNI 加密密鑰放在 DNS 的 SRV 記錄中。

然而，這方面的確切細節仍在不斷變化，因為規範尚未最終確定。 儘管如此，Mozilla Firefox 和 Cloudflare 已經將 ESNI 的實現投入生產。

保護和加密 DNS

為了使 ESNI 密鑰在不被攔截的情況下交付，重要的是要防止 DNS 篡改。

早在 1993 年，互聯網社區就一直在努力保護 DNS。 IETF 指出，早期的問題解決會議討論了：

1. 防止將 DNS 數據洩露給未經授權的各方
2. 確保數據完整性
3. 數據源認證

這些會議促成了 1997 年的域名系統安全擴展 (DNSSEC) 標準。該標準選擇解決其中三個問題中的兩個，因為設計團隊明確決定將所有數據洩露威脅明確排除在範圍之外。

因此，DNSSEC 意味著用戶可以相信他們的 DNS 查詢的答案是域所有者想要的。 在 ESNI 的上下文中，這意味著我們知道我們收到的密鑰沒有被篡改，幸運的是，當使用 DNSSEC 時，上面提到的許多漏洞都會消失。 但是，它不能確保隱私，因此仍然容易受到監視和審查系統引入的問題的影響。

不幸的是，由於它與“不安全的 DNS”完全向後兼容並且很難正確實施，因此 DNSSEC 的採用率非常低。 許多域所有者在嘗試配置它的過程中放棄了，這在野外看到的許多無效和半設置配置證明了這一點。

HTTPS 上的 DNS (DoH)

為了在觀察者不知道用戶試圖訪問哪個站點的情況下交付 ESNI 密鑰，防止 DNS 竊聽非常重要。 因此，說加密的 DNS （例如使用 DoH）是一件好事是非常合乎邏輯和可以理解的。 然而，就目前而言，DNS 並未加密。

Mozilla、谷歌、APNIC、Cloudflare、微軟和其他公司正在採取行動來改變這一點。

理想的加密用戶體驗

當涉及到使用加密的實際 UX 細節時，想要利用上述技術的用戶可能有相當長的要求列表。 很可能，他們希望避免以下情況：

• 被迫使用特定的 DNS 服務提供商（無論它有多好）或選擇不可見或難以找到
• 設備上的每個應用程序處理 DNS 的方式不同（例如，Firefox 可以找到 Safari 無法找到的東西）
• 設備上的所有應用程序都必須在自身內部創建自己的安全 DNS 實現
• 必須多次手動配置 DNS
• 不得不選擇隱私和安全
• 應用程序在未經用戶同意的情況下退回到不安全的操作

有隱私意識的用戶會想要：

• 不受任何人無端監視的隱私
• 防止他們未同意的定向廣告
• 保護他們自己發布的內容（例如，在個人網站上）在傳遞給其他查看者的途中不被更改或操縱
• 確保他們自己發布的內容的查看者不會僅僅因為訪問它而陷入麻煩
• 繼續擁有在他們自己的網絡上控制 DNS 的選項（因為有時，水平分割 DNS 有利於將內部資源限制在內部用戶範圍內）
• 在 DNS 級別選擇加入或至少退出過濾的能力（例如，Quad9、CleanBrowsing 和 OpenDNS Family Shield）
• 簡單、無憂的配置（即 DHCP）
• 被要求同意使用不加密的 DNS
• 不僅保護瀏覽器流量，還保護所有類型的流量，例如電子郵件、Slack、VoIP、SSH、VPN 等。

當前的加密努力

具有上述目標的用戶有哪些選擇？

Mozilla 的解決方案是一個開始，但遠非理想。 他們只是保護 Firefox； 默認設置是覆蓋您的操作系統設置以支持他們選擇的提供商（Cloudflare）而不這麼說，它會默默地退回到不安全的狀態（在加密 DNS 被阻止等情況下）

谷歌的解決方案是一種更好的方法。 他們正在保護適用於所有應用的 Android 9+。 （我不確定他們對 Chrome OS 的計劃，但我懷疑它正在開發中。）他們還在所有平台上保護 Chrome，但它僅在主機平台配置為使用支持安全性的提供程序時才會觸發安全性。 這在用戶選擇方面很好，但並不理想，因為它會默默地退回到不安全的狀態。

所有其他主要瀏覽器也在實施支持。

在用戶的理想情況下，更廣泛的軟件和操作系統開發人員社區將：

1. 停止在應用程序級別實施新的 DNS 安全功能
2. 開始在操作系統級別實現它們
3. 尊重操作系統級別的配置，或徵得用戶同意

在操作系統級別實施加密 DNS，我們可以繼續遵循我們目前用於 DNS 解析器的相同分佈式模型。 在自己的網絡上運行自己的 DNS 服務器，並能夠使解析器安全，繼續作為一種選擇是有意義的，就像使用集中式提供商一樣。

Linux 和 BSD 已經具有此功能，並有多種可用選項。 不幸的是，據我所知，沒有發行版默認啟用它們中的任何一個。 如果您想要插入 glibc 的東西，請查看 nss-tls。

Google 在 Android 9+ 中的 DNS-over-TLS 實施也已經這樣做了。 它通過測試 DNS 服務器的加密支持來發揮作用。 如果它有它，那麼它將使用它。 如果沒有，那麼與 Chrome 一樣，它會以不安全的方式繼續運行，無需提示同意。

值得注意的是，大多數網絡都配置為使用不支持加密的 DNS 服務器，因此 Android 內置的解決方案對大多數用戶來說並沒有改變任何東西。 在去中心化不支持加密的情況下，提供回退到集中式加密 DNS 可能會更好。

對於 Apple 和 Microsoft 風格的設備，在撰寫本文時，對加密 DNS 的支持尚未正式到來。 隨著微軟在 2019 年 11 月宣布他們打算支持加密 DNS，希望蘋果很快就會跟進。

加密 DNS 解決方法

有一些可以在本地運行的代理形式的解決方法。 有了這些，用戶的計算機會向自己發送非加密的 DNS，然後它會向配置為使用的任何提供商發送加密的 DNS。 這不是一個理想的解決方案，但隨著變通方法的發展，它是不錯的。

寫這篇文章的靈感來自 DNSCrypt 代理，它非常穩定，有很多花里胡哨，而且是跨平台的。 它支持較舊的 DNSCrypt 協議，以及較新的 DNS over TLS (DoT) 和 DNS over HTTPS (DoH) 協議。

對於 Windows 用戶，有一個名為 Simple DNSCrypt 的安裝程序和 GUI，它功能齊全且非常易於使用。

我推薦它，但請注意，世界可能還沒有為您準備好，您可能需要不時禁用它（例如，當您必須在您最喜歡的咖啡館或 LAN 中使用強制門戶時派對）。

其他選項

此外，還有支持加密 DNS 的 Technitium DNS 服務器，它是跨平台的（Windows、MacOS、ARM/Raspberry Pi 上的 Linux），並具有流暢的 Web 界面。 它在“其他”之下，因為它更像是一個全方位的工具，而不是針對這個問題的解決方案。 （如果您想在家中運行 Raspberry Pi DNS 服務器，這可能是一個不錯的選擇。我很想在下面的評論中聽到嘗試它的人的反饋。）

對於您的 Android 或 iOS（iPhone、iPad 等）設備，還有 1.1.1.1 應用程序，它將強制您通過 Cloudflare 加密 DNS 服務進行所有 DNS 查詢。 我聽說還有更靈活的應用程序，例如 Intra，但我還沒有花時間測試它們。

當然，您也可以在 Firefox 和 Chrome 中啟用加密 DNS - 請記住上面討論的所有註意事項。

DNS 可靠性：第一號工作

互聯網隱私技術存在很多爭議。 但是，在實施安全和隱私措施時，所討論的技術主要不是保密。 這是關於確保可靠性並保證技術繼續正常運行，儘管其他人的行為。 然而，我們需要注意，就像沒有隱私保護的技術是不好的一樣，實施不善的保護只會使情況變得更糟。