DNS 隱私、安全性雜記

各協定適合的使用情境、服務商及工具筆記。

DNSSEC

為 DNS 紀錄加上電子簽章的技術。由上層網域簽認下層網域的簽章公鑰,下層網域的簽章公鑰可以拿來驗證該網域紀錄的真實性,構成信任鏈的概念。不過因為是簽章,不是加密,所以對使用者查詢了什麼並沒有保密效果,而是保證 resolver 不會被偽造的 DNS 回覆騙到。

DNS over TLS (DoT)

通常是作為 end user 跟 resolver 間加密溝通用,可以拿來防止被從中竊聽。感覺 2018 年才開始受到重視。

DNSSEC 跟 DNS over TLS 彼此互補

單就資料真實性而言,如果所有的 DNS servers 彼此之間都採用 DoT 互相溝通當然是可以做到沒錯,但是就我想到有幾個比較大的問題:

  • DoT 目前還是採用 TCP,傳統 DNS 就算加掛了 DNSSEC 仍是 UDP 為主。UDP 因為不需先連線,server 反應速度及乘載量會優於 TCP 的方案。Resolver 解析出一條網址常常要跟多個 authoritative servers 要資料,累積起來效能衝擊太大,影響 end user 使用體驗。(未來或許會有轉機?
  • DoT 加密連線用的憑證仍仰賴傳統的憑證簽發體系,如何決定要信任哪幾家 root CA 這背後問題很多。若憑證簽發單位簽出不符合安全規範的憑證,外部使用者也無從檢核起,卻會認證通過;DNSSEC 則開放即時查詢,且自主性高,網域管理人可以在自己 DNS 網域下放任何資料並獲得真實性驗證,有顛覆傳統憑證簽發體系的潛力
  • 擴展性跟事後可驗證性的問題。因為 DNSSEC 信任的基礎是簽章,而非通訊的對象,所以不管是誰給出來的紀錄,只要簽章驗證通過,就可以確認資料真實性。在不給出任何 private key 的情況下,別人透過快取等機制也可以給出同樣可信任的資料。如果有可疑的紀錄,使用者也可以把那瞬間的整串資訊(從 root domain 到該紀錄的整套驗證資訊)擷取下來,任何人都可以驗證說在某個時間點真的有奇怪的紀錄被簽認了。反之,如果只有 DoT 的話,因為要靠與特定通訊對象連線才可以驗證,只要遠端一被改,就很難重現問題。

由此可見,兩個技術解決的問題並不相同,不會被彼此取代。

剩下的疑慮

嚴格來說,用 DNSSEC 對紀錄真實性驗證應該要在 end user 這邊做,但要做到這步,就需要從 root domain 一路往下驗證,需要的資料跟 resolver 沒什麼不同。而自己當 resolver,因為對外沒有加密,就有被監聽的問題。

如果要不怕監聽,就得很多人共用一個 resolver,讓監聽者監聽 resolver 的明碼傳輸部分也不知道是哪個 end user 發來的請求。

目前簡單的方法是透過 DoT 來用某家很多人用的 resolver,然後相信它 DNSSEC 驗證會好好做,而且不會偷偷紀錄你的查詢。基本上,說自己會收資料的一定有收,說自己不收資料的也無法檢驗它到底收不收。 😅

自架 resolver 走 Tor 出去查詢當然是一個方法,就是效能跟架設複雜度對一般使用者有門檻。

工具

大部分可以參考 DNS Privacy Project 底下的 DNS Privacy Clients,這邊只對裡面缺的做補充。

Unbound

這個 commit 來看,forward-tls-upstream 是 1.7.0 之後才有的功能,如果要用 DoT 最好用這個之後的版本。

kdig

如果不想編譯或是安裝,Docker 裡面有個 cznic/knot image 可用。

docker run --rm cznic/knot kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com

各家 DoT Public Resolver 實作細節

有趣的是,除了 DNS Privacy Public Resolvers 上面列的 Cloudflare, Quad9 這些,TWNIC 也跟風,推出 Quad 101。 😂

蠻好奇在台灣弄一個這樣的「開放服務」用意在哪?畢竟 Cloudflare 在台北是方電訊有機房空間,沒了地理優勢,技術上要做得比他好也不是那麼容易;稽核上,Quad 101 說有 PwC Taiwan,Cloudflare 也說有 KPMG 啊!唯一說得通的就是自架服務才有得「親自」稽核,然後開放才有多一些人來用,可以混淆監聽者的視聽。有稽核這個服務的權限,又會有這樣需求的單位,嗯…… 🤫

有點怪的是 Quad 101 的 IPv4 支援 DoT,IPv6 卻沒有。所以

kdig -d @101.101.101.101 +tls-ca +tls-host=101.101.101.101 example.com

正常,但是

kdig -d @2001:de4::101 +tls-ca +tls-host=101.101.101.101 example.com

就不行了。

憑證

撈這個也蠻有趣的。跑幾個像這樣的指令

#IPv4
echo -n | openssl s_client -connect 1.1.1.1:853 | openssl x509 -noout -text | less

#IPv6
echo -n | openssl s_client -connect [2606:4700:4700::1111]:853 | openssl x509 -noout -text | less

就可以撈出各家憑證內容

Hosted by Issuer Auth. Level Alt. Name
Cloudflare DigiCert OV DNS: *.cloudflare-dns.com
IP Address: 1.1.1.1
IP Address: 1.0.0.1
DNS: cloudflare-dns.com
IP Address: 2606:4700:4700:0:0:0:0:1111
IP Address: 2606:4700:4700:0:0:0:0:1001
Google Google OV DNS: dns.google
IP Address: 2001:4860:4860:0:0:0:0:64
IP Address: 2001:4860:4860:0:0:0:0:6464
IP Address: 2001:4860:4860:0:0:0:0:8844
IP Address: 2001:4860:4860:0:0:0:0:8888
IP Address: 8.8.4.4
IP Address: 8.8.8.8
DNS: 8888.google
Quad9 Let’s Encrypt DV DNS: dns.quad9.net
DNS: dns.rrdns.pch.net
Quad 101 COMODO OV IP Address: 101.101.101.101

Quad9 用免費的 Let’s Encrypt 只能放 DNS 不能放 IP 也就算了,TWNIC 既然都特別花了錢買憑證,為何不學 Cloudflare 把所有的 IP 跟 DNS (twnic-public-dns.twnic.tw) 都塞進去我就不太曉得。

Cloudflare 不愧是專業的,憑證做得最完整,反應速度也海放其他家。硬要雞蛋裡挑骨頭的話,就只差沒把那些 IP 的反向 PTR DNS (one.one.one.one) 放進憑證裡了。

備註

當然還有 DNSCrypt,但它一直沒有變成比較像標準的東西,在 DoT 出來之後應該會慢慢淡出了吧!

DNS over HTTPS 的問題則是各家標準似乎仍不太一致:

RFC 8484 出來之後應該會有改善?

在特殊環境下(例如 DoT 連線被擋)需要繞過 firewall 時,倒是可以試試。

不要問我為什麼不討論 CleanBrowsing會擋成人內容的 DNS 根本不配被稱為 DNS!

參考資料

Posted in Technical.

Leave a Reply

Your email address will not be published. Required fields are marked *

Captcha loading...