Handshake domain 區塊鏈網域 —— 如何訪問網域
在前篇我們成功把網域給標到手了！區塊鏈網域和其它常見的 NFT 可不一樣，它不只是個所有權憑證，它寫在鏈上的資訊還能導向我們的伺服器位置。Handshake domain 是個已經有實作的專案，整個架構是能運行的。要把它使用起來，我們有兩個面向要設定，一邊是伺服器方；一邊是訪問方 —— 伺服器方要起動一台 DNS 主機，並由鏈上指向它；訪問方要把自己的解析器替換為 Handshake resolver。
這篇將講解如何設定訪問方，使自己能訪問 Handshake 網域，並且在文末探討有關憑證驗證的議題。
如何訪問 Handshake 網域
Handshake 的解析器有不少實作，完整清單在此。以下介紹幾個不錯的方案。
請用 welcome.nb/ 進行測試
輸入時注意最後方的斜槓，以免某些瀏覧器啟動搜尋功能
HNS↗TO - 不用做任何設定
網址: hns.to
hns.to 是一個 Handshake 的網關服務，它能以傳統 DNS 訪問，並代理 Handshake 網域的內容給你。在瀏覧器直接訪問 "hns.to/"+Handshake 網域，例如 "hns.to/welcome.nb/"，它會自動導向至 http://welcome.nb.hns.to/，並返回 welcome.nb/ 的內容給你。它很方便，但這一定不安全，所有流量都會經過它們家的伺服器。
這適用在暫時提供未設定 Handshake domain 環境的圈外人使用，請不要把它視為正式用途。
Bob Extension (Chrome Extension)
網址: https://chrome.google.com/webstore/detail/bob-extension/ogcmjchbmdichlfelhmceldndgmgpcem
它是一個瀏覧器內錢包，由社群維護。除了常見的和 dapps 互動以外，它還提供瀏覧器內 proxy 功能 —— 將 Chrome 的 DNS 查詢導向到 HNSD 解析器。預設它會使用公開的 HNSD 主機，你可以在設定中改成指向你自己的解析器。
我不推薦使用這個 Extension 做 Proxy。猜也知道，Let's Encrypt 不支援發行 Handshake domain 的 TLS 證書，所以我在個人主機上使用自簽憑證。當訪問網頁時會出現 ERR_CERT_AUTHORITY_INVALID，按「繼續」或輸入 thisisunsafe 以訪問，這還算能接受。但是經過 Extension Proxy 後，此錯誤會變為 ERR_PROXY_CERTIFICATE_INVALID，並且無法手動允許。無法訪問是要我怎麼用..
NextDNS - 內建 Handshake 域名解析的 DNS 提供商
NextDNS 公司是一家 DNS 解析器提供商，允許用戶設定 DNS Filter 以過濾 DNS 查詢。NextDNS 每月提供 30 萬筆查詢次數的免費額度，如果你需要更多流量，訂閱制為 NT$70 / 月、NT$700 / 年。他們內建非常多的 DNS 過濾清單、追蹤清單，甚至有 AdGuard 的清單。最重要的，它們可以解析 Handshake 域名。
如果你不自己架設解析器，那麼 NextDNS 是最理想的選擇了，若你的用量不會超出免費額度的話。NextDNS 網站有完整的設定教學，你可以把它設定在瀏覧器層級；電腦 OS 層級；或是路由器層級。NextDNS 是一家頂尖的 DNS 提供商，而它們支援 Handshake 這件事，無疑是給 Handshake 社群帶來很大的肯定。
題外話，我個人目前使用 NextDNS 做手機的 DNS Filter
不愧是小米手機，追蹤數據一半送美國、一半送大陸
中美大數據我兩邊都參與到了耶┌(。Д。)┐
HNSD - SPV light node
網址: https://github.com/handshake-org/hnsd
HNSD 由社群維護，是 Handshake 網路的 SPV 解析器。它會和其它 HSD full node 建立 P2P 網路，向其它 full node 詢問網域解析，並驗證獲得的回應。HNSD 本身不儲存任何資料，只在 DNS cache 滿載時使用 12MB 的 memory。
自行架設 HNSD 時，能夠保證你的瀏覧不經過其它第三方外部主機。HNSD 的優點在於它的運行成本很低，並不是每個人的環境都有足夠強大的機器，儲存 20GB 且持續增長的區塊鏈以運行完整的 HSD 節點。但由於它依賴外部的 full node 查詢區塊鏈，它不是一個安全的解決方案。
你可以在本機電腦運行它，並把瀏覧器 DNS 指向它；或是在內網的 NAS 上運行它，把電腦的 DNS 指向它。
Fingertip - HNSD + letsdane + go-ethereum 的 Proxy server
網址: https://impervious.com/fingertip.html
這是一個開源的 Proxy 伺服器，內建 HNSD 以解析 handshake 網域，整合了 letsdane 以驗證 DANE 憑證，還整合 go-ethereum 以解析.eth 域名 (ENS 域名)。安全性考量請參考上方 HNSD 的描述，除了 Proxy Server 和 DNS Server 差別外，其餘在定位上差不多。
HSD - full node
網址: https://github.com/handshake-org/hsd
自行運行 HSD 完整節點當然是完全分散式、最隱私、且最安全的做法。你持有完整的區塊鏈，並且直接在上頭查找網域資訊。
探討關於 Handshake 的憑證信任驗證機制
在 Namebase 的說明文件上有探討這個主題
https://learn.namebase.io/about-handshake/about-handshake#a-more-secure-internet
CA 憑證的介紹，請見外站連結
HTTPS/SSL/TLS 概述，整體流程、憑證、數位簽章 - iT 邦幫忙
https://ithelp.ithome.com.tw/articles/10193095
你的電腦上出廠就安裝了數百個 CA —— 微軟有 390 個證書，而 Mac OS X 有 170 個證書。為了「安全」地瀏覽網頁，你必須信任所有這些 CA 以及它們委託的許多中介機構。如果這些機構中哪怕任何一個有惡意行為或被駭客攻擊，那麼你所有的 HTTPS 互聯網瀏覽流量都會受到影響，容易受到 MITM 中間人攻擊。**在 DigiNotar 事件中，伊朗政府駭掉了一個荷蘭 CA，並利用它對 30 萬伊朗公民進行 MITM 攻擊。**這又是一個中心化架構的缺陷，而 Handshake 能解決這個問題。
Handshake 網域以區塊鏈作為自己的信任根，並將其 TLS 密鑰釘在自己身上。
Handshake 不是依靠「由數百個證書頒發機構組成的任意集中式列表」來驗證公鑰的真實性，而是通過「將信任根轉移到一個有密碼支持的分佈式信任根」也就是區塊鏈，使任何人都可以驗證密鑰的真實性。與傳統網域不同的是，只需要一個壞的證書頒發機構就可以破壞你的安全，而在 Handshake，駭客得要造假整個 Handshake 區塊鏈。
CA 驗證的主要目標是「讓客戶端確定其取得的網頁，是由被權威驗證過的伺服器所發出」。「申請人被權威驗證過」，並且因為只有該伺服器能送得出憑證，「網頁沒有在中途被調包」。區塊鏈網域的本質就是要脫離權威審察，在這裡並沒有被信任的權威，也沒有人能審察你的網域註冊。「申請人被權威驗證過」不一定是好事，因為權威可能不被信任，尤其這些機構都在各大政府的掌控之下。再說，現在由 Let's Encrypt 可以很簡單的取得被瀏覧器信任的憑證。若看到一家正規公司的憑證由 Let's Encrypt 簽發當然是件不正常的事，但它一樣都會顯示綠色鎖頭🔒。
在區塊鏈的世界中，鏈上的資訊是不可能假的。我們使用自簽憑證，將此憑證的雜湊寫到 Handshake 鏈上，並在網頁上提供此憑證。客戶端將憑證和鏈上寫的資訊作比對，以查覈此網頁是由網域擁有者所送出，「網頁沒有在中途被調包」。整個信任基礎由「權威認證的信任樹」改為「網頁確實來自網域所有者」。今天你來到 blog.maki0419/ 看到了綠色鎖頭，你想知道的是這確實是我的網頁，而不是我有向權威繳保護費。DANE 驗證的是更合理的信任基礎。
DNS-based Authentication of Named Entities (DANE) 是一項網際網路安全協議，允許使用 DNSSEC 將通常用於 TLS 的 X.509 數位證書與域名綁定。它是在 RFC6698 中提出的，是一種在沒有 CA 的情況下驗證 TLS 客戶端和服務器實體的方法。
詳細探討請見外站連結
DANE 的過去、現在與未來 - 財團法人台灣網路資訊中心部落格 | TWNIC Blog
https://blog.twnic.tw/2021/04/15/17961/
要在 Handshake 實作 DANE 驗證請讀以下這篇文章，文內講得非常詳細
Building a secure website on your Handshake TLD | by Matthew Zipkin | Medium
對，真有夠複雜
此文撰文時點，主流瀏覧器都不支援 DANE 驗證，客戶端要另起一台 Proxy 來驗。這讓我覺得，在 Handshake 尚未流行的現階段配置 DANE 的意義還不夠大。目前我個人只使用簡單的自簽憑證，確保連線有透過 TLS 加密而已。
結語
你可能很高興的設定好了，但我得在這裡說句實話 —— 就個人體驗來說，上鏈查資料比傳統 DNS 系統要慢上數百倍。當 resolver 中沒有 cache 時，你可能要重覆 F5 個 20 秒才能成功查回 ip，視你的機器效能和網路速度而定。沒有辦法，不像傳統 DNS 是以速度和串串樂為中心的設計，Handshake 是以區塊鏈為中心的設計。只要上鏈就會扯到機器效能，而其結果就是慢。
現在我個人使用 NextDNS，並在平常不使用的 Browser 上設定 DoH，以免超出免費方案。當我要訪問 Handshake 站點，我就打開該 Browser，並多 F5 個幾次讓 NextDNS 建立 cache。目前我的使用量小到不值得我在本地配置 node，並且我也沒有什麼機敏資訊害怕洩漏。以上心得提供給各位參考。
下一篇講講我們身為伺服器方，如何來設定第一個 Handshake domain，實際操作架設一個站點起來。
Comments
You can comment on this blog post by publicly replying to this post using a Mastodon or other ActivityPub/Fediverse account. Known non-private replies are displayed below.