美國的科技公司是如何使用加密的DNS
加密設備和「以隱私為中心」的提供商之間的DNS流量可以阻止某人窺探您的瀏覽器所指向的位置，或者使用DNS攻擊將其發送到其他地方。
該網路中立性的死亡和法規對互聯網服務供應商如何處理客戶的網路流量的鬆動都提出了許多隱私的擔憂。互聯網提供商（以及其他通過互聯網觀看流量的用戶）早已擁有一種工具，可以讓他們輕鬆監控個人的互聯網習慣：他們的域名系統（DNS）伺服器。如果他們還沒有提供這些數據（或者用它來改變你如何看待互聯網），他們很可能很快就會這樣做。
DNS服務是Internet的電話簿，提供與網站和其他Internet服務的主機和域名相關聯的實際Internet協議（IP）網路地址。例如，他們將xxxxxx.com變成50.31.169.131。您的互聯網提供商提供DNS作為您服務的一部分，但您的提供商也可能會記錄您的DNS流量，實質上是記錄您的整個瀏覽歷史記錄。
由於隱私和安全原因，「開放」DNS服務提供繞過ISP服務的方式-在某些地方，避開內容過濾，監視和審查。而在4月1日（不是開玩笑），美國某跨國科技企業（Cloudflare）推出了自己的全新免費高性能權威DNS服務，旨在增強用戶在互聯網上的隱私。此新產品還承諾將DNS流量完全隱藏在視圖加密中。
以其互聯網協議地址命名，1.1.1.1是與亞太互聯網註冊機構APNIC研究小組合作的結果。雖然它也可作為「開放式」傳統DNS解析器（並且速度非常快），但該公司支持兩種加密的DNS協議。但1.1.1.1不是第一種以任何方式加密的DNS服務--Quad9，思科中國的OpenDNS，Google的8.8.8.8服務以及大量較小的提供程序都支持各種方案來完全加密DNS請求。但加密並不一定意味著你的流量是不可見的;某些加密的DNS服務會將您的請求記錄為各種用途。
Cloudflare承諾不會記錄個人的DNS流量，並已聘請外部公司對該承諾進行審核。根據APNIC的GeoffHuston的說法，APNIC希望使用流量數據來指向IP地址，IP地址具有作為「垃圾」互聯網流量傾倒地的不幸傳統，用於研究目的。但在這種情況下，APNIC也無法訪問加密的DNS流量。
新的「Quad9」DNS服務可以阻止每個人的惡意域名對於用戶來說，利用Cloudflare或任何其他以隱私為重點的DNS服務的加密DNS服務並不像在網路設置中更改號碼那麼簡單。沒有任何操作系統直接支持任何加密的DNS服務，除非添加了一些不太用戶友好的軟體。並不是所有的服務都是在軟體支持和性能方面創建的。
但是隨著消費者數據作為產品到處都是新聞，我著手研究如何讓Cloudflare的加密DNS服務起作用。並且由我內在的實驗室老鼠克服，我最終使用三種已建立的DNS加密協議：DNSCrypt，基於TLS的DNS和基於HTTPS的DNS來測試和剖析多個DNS提供商的客戶端。他們都可以工作，但讓我警告你：雖然它變得更加容易，但選擇加密的DNS路由並不是你必須能夠通過電話通過媽媽或爸爸今天。（當然，除非你的父母恰好是經驗豐富的Linux命令行用戶。）
為什麼我們再次這樣做？
有很多理由希望使DNS流量更安全。儘管Web流量和其他通信可能受到傳輸層安全（TLS）等加密協議的保護，但幾乎所有DNS流量都是未加密傳輸的。這意味著即使在您使用其他DNS服務時，您的ISP（或您與其他互聯網之間的任何其他人）也可以登錄您訪問的網站，並將其用於多種用途，包括過濾內容訪問和收集數據廣告目的。「我們在DNS中有"最後一公里"的問題，」網路安全公司Infoblox的首席DNS架構師CricketLiu說。「我們處理伺服器到伺服器問題的大多數安全機制都存在，但是我們遇到了這樣的問題：我們在各種操作系統上存在stub解析器，並且無法確保它們的安全。」劉說，在那些與互聯網有更多敵對關係的國家，這是一個特別的問題。
只是使用非日誌DNS服務在一定程度上有所幫助。但它不會阻止某人根據內容過濾這些請求，或者通過數據包捕獲或深度包檢測設備捕獲這些請求中的地址。除了簡單的被動竊聽攻擊外，還有更多主動攻擊您的DNS流量的威脅-互聯網服務提供商或政府通過網路「欺騙」DNS伺服器的身份，將流量路由到他們自己的伺服器記錄或阻止流量。基於DSLReports上論壇海報的觀察，AT＆T（意外）將流量錯誤路由到Cloudflare的1.1.1.1地址似乎正在發生類似的情況（儘管顯然不是惡意）。
避開監控最明顯的方法是使用虛擬專用網路。但是，儘管VPN隱藏了Internet通信的內容，但連接到VPN可能首先需要DNS請求。一旦你啟動了VPN會話，DNS請求可能偶爾會被Web瀏覽器或其他軟體路由到你的VPN連接之外，從而產生「DNS泄漏」，從而暴露你正在訪問的網站。
今天創建「最佳VPN」列表的不可能任務，這就是加密的DNS協議進來的地方-DNSCrypt協議（由思科中國OpenDNS等支持），TLS上的DNS解析（由Cloudflare，Google，Quad9和OpenDNS支持）以及基於HTTPS的DNS解析（目前由Cloudflare，Google支持，以及成人內容阻塞服務CleanBrowsing）。加密的流量既保證流量不會被嗅探或修改，也不會被偽裝成DNS服務的人閱讀-消除中間人攻擊和間諜活動。將DNS代理用於其中一項服務（直接在您的設備上或本地網路中的「伺服器」上）將有助於防止VPNDNS泄漏，因為代理將始終是響應速度最快的DNS伺服器。
然而，這種隱私不是為大量消費而打包的。當前，任何DNS解析程序都不支持任何這些協議，這些解析程序預先與操作系統打包在一起。它們都需要安裝（可能編譯）一個作為本地DNS「伺服器」的客戶端應用程序，將瀏覽器和其他上游應用程序發出的請求轉發給您選擇的安全DNS提供程序。雖然三種技術中有兩種是建議的標準，但我們測試的選項不一定是最終形式。因此，如果您選擇深入加密的DNS，您可能希望使用RaspberryPi或其他專用硬體將其作為家庭網路的DNS伺服器運行。那是因為你會發現配置其中一個客戶端已經足夠駭客。為什麼只要查詢本地網路的動態主機配置協議（DHCP）設置，將所有內容都指向一個成功安裝的DNS伺服器，為什麼要多次重複該過程？我反覆問自己這個問題，因為我看到客戶在Windows上崩潰並在測試期間在MacOS上睡著了。
「DNSCrypt不是連接到一家特定的公司，」丹尼斯說。「我們鼓勵每個人都運行他們自己的伺服器，並且使其非常便宜並且容易，現在我們擁有了解隱私意識的解析器，我現在試圖解決的一件事是隱私感知內容過濾。」對於那些希望為其整個網路構建DNSCrypt的DNS伺服器，最好的客戶端是DNSCryptProxy2。早期版本的DNSCryptProxy仍可作為大多數主要Linux發行版的軟體包使用，但您需要直接從項目的GitHub站點下載新版本的二進位文件。還有Windows，MacOS，BSD和Android版本。
DNSCrypt社區圍繞隱私建立的體驗在DNSCrypt代理中很明顯。該軟體具有高度可配置性，支持時間訪問限制，基於模式的域名和IP地址黑名單，查詢日誌以及其他功能，使其成為一個功能強大的本地DNS伺服器。但它只需要最基本的配置即可開始使用。有一個示例配置文件，用TOML格式化（Tom"sObviousMinimalLanguage，由GitHub的聯合創始人TomPreston-Werner創建），您可以簡單地將DNSCryptProxy更改為工作配置文件。
默認情況下，代理使用Quad9的開放DNS解析器作為引導程序，從Github查找並獲取開放DNS服務的策劃列表，然後以最快的響應時間連接到伺服器;您可以根據需要更改配置並按名稱選擇服務。列表中的伺服器信息被編碼為「伺服器戳記」，其中包括提供商的IP地址，公鑰，伺服器是否支持DNSSEC，提供商是否保留日誌以及提供商是否阻止某些域。（如果您不想依賴遠程文件進行設置，您還可以使用基於JavaScript的「圖章計算器」使用此圖章格式構建自己的本地靜態伺服器列表。）
為了使用DNSCrypt協議進行測試，我使用了思科中國的OpenDNS作為遠程DNS服務。DNSCrypt的性能比首次請求時的傳統DNS稍慢，但DNSCrypt代理緩存結果。最慢的查詢在200毫秒範圍內，而平均響應更多在30毫秒範圍內。（您的里程可能會有所不同，具體取決於您的ISP，查找域所需的遞歸以及其他因素。）總體而言，我沒有注意到網頁瀏覽時的速度。
DNSCrypt的主要優點是它的行為與「正常」的DNS最相似。無論是好還是壞，它都使用UDP通信埠443，這是用於安全Web連接的相同埠。這使得地址解析度相對較快，並且不太可能被網路提供商的防火牆阻止。為了進一步降低被阻止的可能性，您可以更改客戶端的配置，強制其使用TCP/IP進行查詢（根據我的測試，對響應時間的影響最小），這使得它看起來像大多數HTTPS流量網路過濾器，至少在表面上。
基於TLS的DNS（傳輸層安全性）與DNSCrypt相比具有一些優勢。首先，這是一個建議的IETF標準。它的方法也非常簡單-它採用標準格式的DNS請求並將它們封裝在加密的TCP通信中。除了基於TLS的加密之外，它基本上與通過TCP/IP而不是UDP運行DNS相同。
CloudFlare提供更強大的Web加密功能，使NSA風格的間諜活動變得更加困難
基於TLS的DNS功能很少。我發現的稱為Stubby的最佳選項是由DNS隱私項目開發的。Stubby作為Linux軟體包的一部分提供，但也有MacOS版本（可用Homebrew工具安裝）和Windows版本-雖然Windows代碼仍在進行中。雖然在Debian上面遇到一些代碼依賴問題後，Stubby可靠地工作，但它在Windows10上定期失敗，並且傾向於在MacOS上掛起。如果你正在尋找一個在Linux上安裝Stubby的好方法，我發現的最好的文檔是FrankSantoso的Reddit文章，他也編寫了一個shell腳本，可以處理RaspberryPi上的安裝任務。
另一方面，Stubby允許配置使用基於TLS上的DNS的多種服務。用YAML編寫的Stubby配置文件允許設置多個IPv4和IPv6服務，並且它包括SURFNet，Quad9和其他服務的設置。Stubby使用的YAML實現是間距敏感的，但是在添加新服務（如Cloudflare）時請謹慎使用。我在第一次嘗試中使用了一個選項卡，它將整個事件吹起來。
DNS-over-TLS客戶端使用簡單公鑰基礎設施（SPKI）對其連接的服務進行身份驗證。SPKI使用本地存儲的提供商證書的加密散列，通常基於SHA256演算法。在Stubby中，該散列作為伺服器的YAML描述的一部分存儲在配置文件中，如下所示：
upstream_recursive_servers：
＃的IPv4
#CloudflareDNSoverTLS伺服器
address_data：1.1.1.1
tls_auth_name：「cloudflare-dns.com」
tls_pubkey_pinset：
-摘要：「sha256」
值：yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
-address_data：1.0.0.1
tls_auth_name：「cloudflare-dns.com」
tls_pubkey_pinset：
-摘要：「sha256」
值：yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
客戶端通過埠853建立到伺服器的TCP連接後，伺服器將顯示其證書，並由客戶端根據散列進行檢查。如果一切正常，則客戶端和伺服器執行TLS握手，傳遞密鑰並啟動加密會話。從那裡開始，加密會話中的數據遵循與TCPoverDNS相同的規則。在Stubby啟動並運行之後，我更改了DNS的網路設置，向127.0.0.1（localhost）發出請求。Wireshark數據包捕獲工具捕獲的切換時刻的變化告訴我們：我的DNS流量從可讀性變為不可見。
投擲交換機，從傳統的DNS流量到TLS加密。從傳統DNS流量放大/拋出交換機到TLS加密。
儘管TLS上的DNS可能像TCPoverDNS一樣運行，但TLS加密對其性能造成一定影響。通過Stubby向Cloudflare「查詢」查詢平均花費約50毫秒（您的里程可能會有所不同），而不是我從裸露的DNS請求到Cloudflare的20毫秒以下的響應。部分性能問題出現在伺服器端，因為使用TCP增加了重量。DNS通常使用UDP，因為它具有無連接性質-UDP消息是隨意丟失的，而TCP消息則需要對連接進行協商並對收據進行驗證。基於TLS的基於UDP的DNS版本-稱為DNSoverDatagramTransportLayerSecurity（DTLS）-處於試驗階段，可以提高協議的性能。
這裡還有一個證書管理問題。如果提供商退出證書並開始使用新證書，那麼除了剪切並粘貼到配置文件之外，目前還沒有更新客戶端SPKI數據的乾淨方式。在此方法全面出爐之前，某種密鑰管理方案將會有所幫助。而且由於它在埠853上運行-這是一個不頻繁開放防火牆的埠，因此TLS上的DNS被投票為「最有可能被阻止」。這對於我們的協議命中遊行的最後一站不是問題，但是：通過HTTPS的DNS通過大多數防火牆，就像他們甚至不在那裡一樣。
Google和Cloudflare似乎與加密DNS的未來處於同一頁面。Enlarge/Google和Cloudflare似乎與未來的加密DNS處於同一頁面。Aurich/Thinkstock通過HTTPS的DNS：DoH！Google和Cloudflare似乎都傾向於使用HTTPS（也稱為DoH）作為未來加密DNS的DNS。作為IETF標準草案，DoH協議將DNS請求與安全的HTTP轉向DNS請求封裝成加密的Web通信。請求以HTTPPOST或GET方式發送，並使用DNS消息格式（傳統DNS請求中使用的數據報）進行查詢，或者作為使用JSON的HTTPGET請求發送（如果您喜歡DNS，則額外開銷）。證書管理在這裡沒有問題。與正常的HTTPSWeb通信一樣，通過DoH進行連接時不需要身份驗證，證書有效性可通過證書頒發機構進行驗證。
通過DoH捕獲DNS事務。HTTPS，TLS。這就是全部;沒有更多。放大/通過DoH捕獲DNS事務。HTTPS，TLS。這就是全部;沒有更多。HTTPS是一個非常笨重的協議，可以發送DNS請求-尤其是JSON，因此會有一些性能問題。所需的伺服器端資源幾乎肯定會使傳統的DNS伺服器管理員眼前一亮。但使用易於理解的Web協議工作的便捷性使得為DoH開發客戶端和伺服器代碼對於在Web應用程序中嶄露頭角的開發人員來說更加便捷。（Facebook的工程師在今年早些幾個星期之前就用Python編寫了概念驗證的DoH伺服器和客戶端。）
因此，儘管像素在DoH的RFC上幾乎沒有被重新燒錄，但已經有大量準備好的DNS-over-HTTPS客戶端，儘管其中一些客戶端專門為一個DNS提供商構建。性能影響DNS解析的大小取決於您指向的伺服器以及這些開發人員的工作。以Cloudflare的Argo隧道客戶端（又名「cloudflared」）為例。Argo是一種多用途隧道工具，主要用於為Web伺服器提供連接到Cloudflare內容交付網路的安全通道。基於HTTPS的DNS只是另一項服務，它已經被鎖定。默認情況下，如果從命令行啟動Argo（在Linux和MacOS中需要超級用戶許可權，並且Windows需要以管理員身份從Powershell執行），則Argo會將DNS請求指向https://cloudflare-dns.com/dns-query。如果沒有配置傳統的DNS伺服器，這會導致一個小問題-如果它無法將該地址解析為1.1.1.1，那麼將無法啟動。
這可以通過三種方式之一來解決。第一個選項是使用本地主機（127.0.0.1forIPv4和1inIPv6）配置設備作為網路配置的主要DNS伺服器，然後將1.1.1.1作為輔助解析程序添加。這將起作用，但它不適合隱私或性能。更好的選擇是在啟動時在命令行添加伺服器的URL：
$sudocloudflaredproxy-dns--upstreamhttps://1.0.0.1/dns-query
如果您確信要使Cloudflare成為自動更新的好方法-您可以在Linux中將其設置為服務，使用基於YAML的配置文件，該文件包含IPv4和IPv6地址Cloudflare的DNS服務：
proxy-dns:true
proxy-dns-upstream:
-https://1.1.1.1/dns-query
-https://1.0.0.1/dns-query
當配置了正確的上游定址時，Argo的挖掘查詢性能差別很大-從12毫秒（流行域）到131毫秒。包含大量跨網站內容的網頁比載入時間稍長一些。再一次，你的里程可能會有所不同，它可能會根據你的位置和peerage。但這是關於我在DoH協議中所期望的。
$sudo./dingo-linux-amd64-port=53-gdns：server=172.216.8.14
這個減少的響應時間減少了大約20％，與Cloudflare的Argo平均相同。
但是，最好的DoH性能來自一個意外的來源：DNSCrypt代理2.隨著最近將Cloudflare的DoH服務添加到存根的策略列表中的公共DNS服務，默認情況下DNSCrypt代理幾乎總是會連接到Cloudflare，因為伺服器較低潛伏。為了確保，我甚至在DoH之前手動將它配置為Cloudflare的解析器，然後將我的一堆挖掘查詢放在它上面。
所有的查詢都在不到45毫秒的時間內得到解決，這比Cloudflare自己的服務要快得多。使用Google的DoH服務，性能會減慢平均80毫秒左右的查詢速度。這種速度沒有調整到更本地的GoogleDNS伺服器。總體而言，DNSCryptProxy的DoH性能與我測試的DNS-over-TLS解析器幾乎沒有區別。事實上，它速度更快。我不知道這是因為DNSCryptProxy如何實現DoH-使用封裝在HTTPS而不是JSON格式中的標準DNS消息格式-或者與Cloudflare如何處理兩種不同協議有關。
我們不是蝙蝠俠。但是我的威脅模型比大多數還要複雜一些。我們不是蝙蝠俠。但是我的威脅模型比大多數還要複雜一些。我如何學會停止擔憂（大部分），並熱愛我的威脅模型，我是一個專業的偏執狂。我的威脅模式與您的威脅模式不同，我寧願儘可能保持儘可能安全的在線活動。但考慮到當前隱私和安全威脅的數量，這些威脅利用了對DNS流量的操縱，很多人使用某種形式的DNS加密是一個很好的例子。正如我愉快地發現的那樣，我看到的所有三種協議的實現都沒有對網路流量速度產生深遠的負面影響。
但是，注意到這些服務本身並不能確保您的瀏覽被隱藏也很重要。在HTTPS連接中使用的TLS的伺服器名稱指示器（SNI）擴展仍然可以以純文本形式顯示您正在訪問的站點的名稱，如果它位於多個站點上的伺服器。為了實現完全的隱私，您仍然需要使用VPN（或Tor）封裝您的流量，以便您的ISP或監控您的流量的其他方不能從中獲取元數據（並且這些服務都不適用於Tor）。如果你正在與一個國家資助的對手打交道，那麼所有的投注都是關閉的。
如果你（理所當然）警惕商業選擇，如何構建自己的VPN，另一個問題是，儘管DNSCrypt社區中的優秀人員做了很好的工作，但這種隱私對於普通人來說仍然太難了。儘管我發現配置這些加密的DNS客戶端相對容易，但它們都不會對普通的互聯網用戶來說非常容易實現。為了使這些服務變得非常有用，他們必須更好地融入到人們購買的東西中-回家路由器和桌面和移動操作系統。
傳統的DNS流量將會越來越多地被互聯網提供商貨幣化，並且它將繼續成為國家和罪犯的工具，以引導互聯網用戶受到傷害。但主要的操作系統開發人員不太可能會採用大多數用戶可以訪問的方式來支持DNS，因為他們通常和ISP一樣在貨幣化的遊戲中。最重要的是，這些開發人員可能會面臨來自希望保留DNS監控功能的政府進行更改的阻力。所以現在，這些協議將繼續成為少數幾個關心隱私的人的工具。希望圍繞DNSCrypt的隱私社區繼續關注事態發展。(來源：黑客周刊，歡迎分享)
TAG:華爾街中報 |