DANE 的過去、現在與未來

作者:中華電信 林方傑工程師

DANE是為了緩解什麼問題?

關於DANE(DNS-based Authentication of Named Entities)問世的理由,筆者認為必須從「在網路上安全傳輸」的需求講起。資訊安全至少有CIA三個面向[1],我們先關注其中的「Confidentiality」。如何避免所傳送的資料遭竊取?「加密傳輸」是理所當然的對策。而加密傳輸最直覺的做法,是由連線兩端約定好加解密的關鍵(如對稱式加密金鑰),只要協議夠複雜且未被外界得知,則資料的隱密性在傳輸過程中應可得到一定程度的保障。

但有個衍生的(類似雞生蛋、蛋生雞的)問題是,在尚未完成加密傳輸協議的情況下,連線兩端如何確保加解密關鍵不被第三方得知呢?這時「非對稱加密演算法」的「以公鑰加密只有對應之私鑰可解密」之特性便能派上用場。由於私鑰只應由金鑰製造者持有,選用對應公鑰來加密訊息便確保了只有私鑰製造/持有者可解密[2]

然而,這又會衍生另一個問題,若誤將駭客的公鑰當作原連線對象所提供,或者連線對象根本是冒名頂替的,則資料仍可能被揭露給非預期的對象。那麼如何確保公鑰與對象正確呢?找第三方掛保證是有幫助的選項。現行「公開金鑰基礎建設」(Public Key Infrastructure,簡稱PKI)[3]機制中,有「憑證頒發機構」(Certificate Authority,CA)當掛保證的第三方,負責將公鑰與公鑰來源方的識別等資訊製成「數位憑證」(digital certificates)供查驗。由於數位憑證是基於「數位簽章」(digital signature)[4]技術,可保障資料的「完整性」(Integrity)與「不可否認性」(Non-Reputation)。在網路世界中,被連線的伺服器便可靠這樣的憑證(實務所需的格式與內容如RFC 5280「X.509」所定義),對外做出「自己是域名的合法代表、是正確公鑰的提供者」等有力聲明[5]

但,CA總是可信嗎?撇開惡意CA或作業疏失導致錯發(mis-issue)憑證,現行「PKIX」(Public-Key Infrastructure for X.509 certificates)機制中,任何CA可為任何域名簽發憑證[6]。這種自由度的風險在於,若一家規模較小的CA遭駭並胡亂為知名公司或服務的域名簽發了憑證,這將給予駭客絕佳的攻擊機會。舉個例子[7],假設Jason架了個網站,並以域名a-example-domain.com搭配CA1簽發的憑證對外提供服務。而駭客可從比較沒那麼有名、審查不是那麼嚴格的CA2也為a-example-domain.com取得另一張憑證,置於假造的站臺主機。如果再搭配快取污染(cache poisoning)等手段誤導終端客戶連上駭客的假站臺,由於CA2的憑證也有效,瀏覽器網址欄同樣有個精美的鎖頭,一般用戶不容易察覺有異。實際案例可參閱2011年DigiNotar遭駭等事件報導[8]

有哪些對策、如何緩解?

因應上述的問題,「憑證透明」(Certificate Transparency,CT)、「HTTP公鑰固定」(HTTP Public Key Pinning,HPKP)等安全機制被提出。前者(CT)要求CA將所簽發憑證都登錄到可供查驗的日誌,但一般認為資訊透明主要補強憑證誤發後偵測與追查,事前的防範則幫助有限[9];後者(HPKP)原理是在HTTP header中指定CA、讓使用者第一次連線取得並記下供後續驗證,但這方法因缺乏彈性已式微[10]

DANE也能用來保護域名免受錯發或濫發憑證的糾纏(是的,主角終於登場)。考量網路連線乃至憑證的簽發本來都與域名息息相關,加上有DNSSEC(Domain Name System Security Extension)這個安全協定可確保DNS所傳遞資料的完整性(data integrity)、來源可驗證性(origin authentication of DNS data),以及可驗證之不存在性(authenticated denial of existence)[11],DNS應該是個不錯的傳遞憑證相關資訊之管道。而DNS紀錄的公開性(任何人都可透過DNS查詢取得)[12]更可讓客戶端直接自域名維運者(DNS operator)取得第一手且可信的「憑證聲明」[13],做為後續查驗憑證的指引或依據。

那麼,DANE(的憑證聲明)可以如何派上用場呢?承前例,如果Jason為a-example-domain.com設定A或AAAA紀錄、定義站臺伺服器IP位址的同時,也透過DNS紀錄對外聲明:「我這域名只該搭配CA1所簽發的憑證」,則當終端客戶被誤導向CA2的假站臺時,就可索取並對照上述Jason關於憑證的聲明,從而獲得發現異常的機會。反過來說,對於CA1(或任何被青睞且被聲明的CA)來說,也可在將a-example-domain.com的憑證簽發給聲稱是Jason的人之前,先透過DNS查詢、參考DNS紀錄所承載的聲明,來確認Jason是否真的有要索取一份本CA的憑證[14]

而除了如上述規範可簽發憑證的CA,限制可用的憑證是哪幾張,甚至直接指定「信任錨點」(trust anchor)[15]都屬於DANE的使用案例(use case)。依照RFC 6394,憑證聲明可分為「CA Constraints」、「Service Certificate Constraints」、「Trust Anchor Assertion and Domain-Issued Certificates」 如下表所列:

CA Constraints 客戶端只應該接受指定CA所簽發的憑證
Service Certificate Constraints 客戶端只應該接受特定的憑證
Trust Anchor Assertion and Domain-Issued Certificates 客戶端只應該接受「域名提供」之信任錨點與憑證

表・DANE的憑證聲明

(筆者翻譯[註6、註14])

其中,「CA Constraints」與「Service Certificate Constraints」由於規範的是憑證或信任錨點,使DANE可做為現行PKIX的輔助,而不只是替代方案。相對的,「Trust Anchor Assertion and Domain-Issued Certificates」則補強了自簽或系出「無」名門憑證的缺陷,如終端客戶、瀏覽器、乃至OS通常不會有這些憑證的信任錨點(以判斷憑證簽發單位的真偽)。在現行PKIX機制下,面對瀏覽器「此網站的安全性憑證有問題」的提醒,終端客戶也只能接受憑證並承擔風險;但在DANE的運作下,終端客戶可基於DNS(SEC)提供的可靠聲明資訊(做為對照組),對所得之憑證有更大的信心。

實作面上,一種新的DNS紀錄類型「傳輸層安全性驗證(Transport Layer Security Authentication,TLSA)」被提出,每一筆TLSA紀錄都有「Usage」、「Selector/Matching」、「Certificate for Association」之欄位,如下表所列:

Usage 選用哪一種憑證聲明(選項如上表所列三項)
Selector/Matching TLS憑證應該如何比對,例如:完整比對,或者只比對雜湊值(hash digest)
Certificate for Association 實際要被比對的資料

表・TLSA紀錄的欄位

(筆者翻譯[註6、註16])

關於各欄位的值域各位讀者可參閱RFC 6698,這裡先不詳述,而再承前例情境示範TLSA紀錄設定的方向:為了聲明終端客戶(針對此服務)只該接受CA1所簽發的憑證,Jason可為a-example-domain.com的https服務提供一筆「_443._tcp.a-example-domain.com」的TLSA紀錄定義如下:

Usage 選擇代表「CA constraint」的值
Selector/Matching 提示待比對資料是如何取得(即如何被驗算),如SHA-1 digest
Certificate for Association CA1本身憑證的雜湊值

表・TLSA紀錄的應用

(筆者翻譯[註6])

綜觀來說,DNS解析與DNSSEC是DANE運作的基石。DNS解析的公開性(指任何人都可查詢)可提高資訊透明度並有助於檢核[17]。DNSSEC應用的數位簽章技術可為DANE基於DNS解析傳遞憑證聲明等資訊的管道增加可信度。而基於域名階層所建構的DNSSEC「信任鏈」(Chain of Trust)也使信任錨點數大為收斂(僅剩DNS root根域名)。相對的,web PKI中每家CA都對應一個信任錨點、且有「任何一家CA可簽發任何域名的憑證」及「不同CA可為同一個域名簽發各自版本的憑證」等備受爭議的自由度[18],使得資安防護在web PKI機制中因可攻擊的點多(每個信任錨點都可能是破口)而更具挑戰性。

DANE的現況與前景

前面都在說DANE的好話,接下來討論些待克服的挑戰與潛在問題,以平衡報導。

首先是DNS相關議題:除了(伺服端)為域名進行DNSSEC簽署的比率待提升,DNS解析的耗時(且DNSSEC牽涉額外、專用DNS紀錄的查詢)[19]、「DNS維運者」隨DANE的發展而在網路資訊安全領域中的戲分越發吃重、會否增加單點失效的風險都需要各界集思廣益。而最關鍵的,客戶端的應用程式會否支援新DNS紀錄的查詢及結果的判讀,目前看來在web領域(即瀏覽器)的接受度與配合度不太樂觀……(據說這與「CAA紀錄」被發展相關,但是另一段故事了)[20]

有趣的是,相對於在web領域的窒礙難行,mail領域對DANE的態度就顯得親切得多。比如微軟就宣布其Windows Server、Office 365等產品或服務支援DANE[21],關於DANE如何為SMTP帶來幫助,則可參閱相關討論[22]

[1] 關於CIA https://www.forcepoint.com/zh-hant/cyber-edu/cia-triad

[2] 關於 HTTPS 原理、對稱式加密、非對稱式加密可參閱 https://medium.com/@RiverChan/基礎密碼學-對稱式與非對稱式加密技術-de25fd5fa537https://www.youtube.com/watch?v=w0QbnxKRD0w 等解說。

[3] 關於 PKI 可參閱 https://zh.wikipedia.org/wiki/公開金鑰基礎建設 等說明。

[4] 關於數位簽章可參閱 https://medium.com/@yellowgirl3614/密碼學-三-數位簽章-f8c6a78da46b 等專文。

[5] 關於數位憑證筆者參閱了 https://medium.com/schaoss-blog/前端三十-28-web-http-和-https-的差別是什麼-21ccafb6f36fhttps://www.ssl.com/faqs/what-is-an-x-509-certificate/ 等介紹。

[6] IETF Journal《DANE: Taking TLS Authentication to the Next Level Using DNSSEC》https://www.ietfjournal.org/dane-taking-tls-authentication-to-the-next-level-using-dnssec/

[7] 引用自 https://docs.microsoft.com/zh-tw/windows-server/networking/dns/what-s-new-in-dns-server

[8] 關於CA遭駭可參閱《Inside ‘Operation Black Tulip’: DigiNotar hack analysed • The Register》https://www.theregister.com/2011/09/06/diginotar_audit_damning_fail/、《Comodo SSL Affiliate | The Recent RA Compromise》https://blog.comodo.com/other/the-recent-ra-compromise/

[9] 關於 CT 的討論筆者參閱 https://blog.apnic.net/2019/07/05/whither-dane/https://certificate.transparency.dev/

[10] 關於 HPKP 的議題筆者參閱 https://zh.wikipedia.org/wiki/HTTP公鑰固定https://blog.gslin.org/archives/2016/09/14/6842/hpkp-遇到的阻礙/

[11] DNSSEC的優點引用自《DNSSEC安全技術簡介》http://www.cc.ntu.edu.tw/chinese/epaper/0022/20120920_2206.html 。

[12] 關於DNS紀錄為公開資料可參閱筆者拙作《重新認識DoT/DoH、DNSSEC的定位與原理》https://blog.twnic.tw/2020/02/27/6205/ 。

[13] 引用同註6,其中「DNS/domain operator」雖然不見得等同於「domain holder」或service owner,但前者一定經後者授權才能扮演此角色。

[14] RFC 6394《Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)》https://datatracker.ietf.org/doc/rfc6394/ 、https://cs.gmu.edu/~eoster/doc/2015-08-US-Telecom-DANE.pdf

[15] 關於 trust anchor、chain of trust 的觀念筆者參閱 https://medium.com/@clu1022/那些關於ssl-tls的二三事-十二-chain-of-trust-f00da1f2cc15https://csrc.nist.gov/glossary/term/trust_anchor

[16] RFC 6698《The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA》https://www.ietf.org/rfc/rfc6698.txt

[17] https://www.farsightsecurity.com/blog/txt-record/caa-records-farsight-20170825/

[18] RFC 6698《The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA》https://www.ietf.org/rfc/rfc6698.txt

[19] 引用自 https://blog.apnic.net/2019/05/27/dns-oarc-30-bad-news-for-dane/ 的 ”extended time taken to perform DNSSEC validation…”

[20] 關於DNS、DNSSEC應用在DANE的意義,DANE所遭遇的反對引用自 https://blog.apnic.net/2019/07/05/whither-dane/

[21] https://techcommunity.microsoft.com/t5/exchange-team-blog/support-of-dane-and-dnssec-in-office-365-exchange-online/ba-p/1275494https://www.theregister.com/2020/04/07/microsoft_dane_office/ 

[22] https://blog.apnic.net/2019/11/20/better-mail-security-with-dane-for-smtp/

Leave a Comment

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

Scroll to Top