左 鵬,賀智謀,袁 夢,張海闊,楊衛(wèi)平

(中國互聯(lián)網絡信息中心,北京 100190)

0 引 言

目前主流的標識解析技術在設計之初，并未過多考慮安全因素，其產生的數據均明文傳輸[1-2]，導致相關協(xié)議在運行過程中存在用戶隱私泄露問題。2013年6月，斯諾登曝光了美國國家安全局的“棱鏡計劃”，披露了美國政府對公眾用戶數據的大范圍監(jiān)控行為，引發(fā)舉世震驚[3]。標識解析系統(tǒng)作為互聯(lián)網應用的入口服務，其解析過程中產生的數據是互聯(lián)網用戶隱私保護的重要環(huán)節(jié)[4]。

針對域名解析隱私保護問題，業(yè)界提出了一些基于加密傳輸的機制，如DoH、DoT等，這些技術標準旨在解決用戶端和DNS遞歸服務器間數據傳送的隱私保護問題，不能覆蓋遞歸服務器和權威服務器間查詢流程[5-6]。2016年，IETF發(fā)布了谷歌公司提出的RFC7871，允許遞歸服務器在外發(fā)查詢過程中攜帶用戶的IP地址，以獲取最優(yōu)的DNS應答[7]，目前谷歌公司的公共遞歸服務8.8.8.8已支持該標準。由于該標準將客戶端的IP地址傳遞到了DNS權威服務器，因此DNS隱私保護問題被進一步拓展到了遞歸服務器和權威服務器的交互環(huán)節(jié)。

截至目前，沒有成熟的技術方案支撐域名解析過程中遞歸服務器和權威服務器各節(jié)點間的加密傳輸，導致此過程中的用戶數據存在隱私泄露風險。為此，本文通過充分調研國內外研究現狀，并借鑒DNSSEC的信任鏈思想，提出一種新的基于加密傳輸的標識解析模型?；谠撃Ｐ?，從客戶端到遞歸解析器，及遞歸解析器到權威服務器的每一步查詢，都通過加密傳輸完成，保障用戶隱私和數據的安全。

1 國內外研究現狀

1.1 基于加密傳輸的DNS

針對域名隱私保護問題，2014年，國際互聯(lián)網工程任務組(Internet Engineering Task Force， IETF)成立了DNS隱私傳輸交換工作組，發(fā)布了基于TLS和DTLS加密傳輸的DNS技術標準[8]。2018年，IETF發(fā)布的RFC8484定義了基于HTTPS傳輸的DNS。此外，丹尼爾.伯恩斯坦提出了基于橢圓曲線加密算法的DNSCurve[9-10]，使用Curve25519交換會話密鑰，在緩存和服務器之間提供認證和加密。這些標準可以較好地解決客戶端和遞歸服務器之間DNS隱私和查詢劫持等問題，但都無法覆蓋DNS遞歸服務器和DNS權威服務器之間的解析流程，且缺乏類似DNSSEC的信任傳遞模型，因此不能解決DNS解析全流程的隱私保護問題。

1.2 基于簽名技術的DNSSEC

2005年，IETF的DNS運維工作組發(fā)布了DNS安全擴展方案DNSSEC，其基于數字簽名技術實現遞歸解析器對DNS報文進行完整性驗證和來源性驗證[11-13]，主要解決類似卡明斯基攻擊之類的數據篡改問題[14-15]。截至2018年底，超過90%的頂級域名已部署實施[16]。實施DNSSEC后，DNS報文仍然通過明文傳輸，因此DNSSEC本身無法解決DNS隱私保護問題。但其建立了權威服務器的信任鏈機制，實現了權威服務器各節(jié)點的信任傳遞，為實現全流程加密傳輸的標識模型提供了借鑒思路。

1.3 域名最小化查詢

2016年，IETF發(fā)布RFC7816，提出了查詢域名最小化的DNS查詢方式[17]。普通的DNS查詢中，用戶查詢的域名全名將暴露給查詢過程中經過的所有權威服務器，容易產生隱私泄露問題。DNS查詢最小化遵循發(fā)送的數據越少，隱私問題就越少的原則[18]，僅向較高級的權威服務器暴露部分域名，從而提升了DNS查詢過程中的私密性。在查詢域名最小化中，遞歸服務器和較低級的權威服務器依然能獲取到用戶所請求的域名全名，同時遞歸服務器仍能記錄用戶所有訪問記錄，查詢域名最小化只能提供較為有限的隱私保護。

1.4 域名廣播技術

域名廣播技術由Federrath等人[19]于2011年提出，主要是將近一段時間內查詢量比較大的域名廣播到用戶機器上。遞歸服務器由于參與到了廣播的過程中，不再直接獲取用戶的訪問記錄，因此可緩解用戶隱私泄露問題。同時，由于熱門域名被緩存在用戶的機器上，域名廣播技術能較大程度地提升用戶的訪問速度。域名廣播技術的問題在于對現有的DNS解析架構改動較大，同時需要在用戶的機器上占用大量空間，部署難度較大。

2 基于加密傳輸的標識解析模型

2.1 模型總體架構

本文提出一種新的基于加密傳輸的全流程標識解析模型，借鑒DNSSEC的思想，并使用加密連接的身份認證機制實現權威節(jié)點的身份認證和信任傳遞，實現遞歸服務器和權威服務器間查詢隱私保護。總體架構如圖1所示，分為安全套接層、傳輸層和應用層，其核心在于應用層實現基于加密傳輸的信任鏈和節(jié)點信任傳遞，將在2.2節(jié)詳細描述。其中，安全套接層采用SSL協(xié)議，為上層提供加密功能。傳輸層作為數據傳輸的管道，采用TCP或HTTP等協(xié)議實現。應用層由樁解析器、遞歸解析器和權威解析器組成，實現基于加密傳輸的標識解析功能。

圖1 系統(tǒng)總體架構

模型的信任鏈部分借鑒了DNSSEC信任鏈的思想，但技術原理和目標問題不同。從技術原理上講，DNSSEC通過電子簽名實現信任傳遞。具體地，各節(jié)點掌握一對或多對非對稱密鑰，使用私鑰對各自數據簽名，并提供公鑰給遞歸服務器用于數據驗證。其中，子節(jié)點將公鑰的摘要提交至父節(jié)點，父節(jié)點對其簽名。遞歸解析器通過驗證該公鑰的摘要并與子節(jié)點的公鑰進行比對，從而驗證子節(jié)點的身份。由此類推，實現各節(jié)點身份認證傳遞。本文模型通過加密連接確保數據的隱私性。加密連接建立的過程中，通信雙方首先驗證對方的身份，之后通過協(xié)商機制選擇加密傳輸所使用的密鑰。在上述過程中，通信雙方的身份通過非對稱加密進行驗證，非對稱加密同時確保了密鑰協(xié)商過程的私密性和可靠性，即使攻擊者對通信進行攔截，也無法獲取密鑰協(xié)商期間的具體內容或對其進行篡改[20-21]。從目標問題上看，DNSSEC主要解決遞歸服務器解析過程中數據被篡改的問題。本文模型主要解決解析全流程的用戶隱私保護問題。

2.2 信任鏈建立

本文模型信任鏈通過加密連接過程中的身份認證和加密傳輸實現。具體地，遞歸解析器首先與根節(jié)點建立加密連接，在此過程中，遞歸解析器根據根節(jié)點發(fā)布的證書對其身份進行驗證。一旦連接建立成功，則根節(jié)點身份認證通過，之后遞歸解析器向根節(jié)點查詢一級節(jié)點的證書信息。由于全程加密傳輸，可保證該證書來自于根節(jié)點且無法被篡改。在獲取到一級節(jié)點證書后，遞歸解析器嘗試使用該證書和一級節(jié)點建立加密連接，一旦連接建立成功，則一級節(jié)點身份得到認證，并繼續(xù)向一級節(jié)點查詢二級節(jié)點證書信息。由此，通過加密連接的身份認證和加密傳輸下級節(jié)點的證書實現權威解析器各級節(jié)點的身份認證。DNSSEC信任鏈與本文模型信任鏈如圖2所示。

圖2 DNSSEC信任鏈與本文模型信任鏈

對比DNSSEC和本文模型，DNSSEC的優(yōu)勢在于可實現數據來源性驗證，即經過DNSSEC簽名后的數據，傳輸鏈路上無論經過何種方式傳輸，鏈路上的任何一方都不需要掌握簽名者的私鑰，最終接收方都可以驗證該數據來自于簽名者。因此，實際應用中，域名擁有者可以對自有數據簽名，再將域名托管至第三方運營，方便簽名業(yè)務和解析托管業(yè)務分離。但DNSSEC的主要局限在于無法實現用戶的隱私保護，由于其使用電子簽名技術，經過DNSSEC簽名后的報文仍然明文傳輸，第三方可以獲取用戶數據并窺探用戶隱私。此外，DNSSEC無法覆蓋用戶端和遞歸解析器間的鏈路，存在“最后一公里”問題[22]。本文模型的優(yōu)勢在于實現了標識解析所有流程的加密傳輸，因此可實現全流程的用戶隱私保護。此外，由于數據加密傳輸，也保障了數據無法篡改。但其局限在于無法實現數據來源驗證，域名擁有者若需托管域名到第三方，則第三方需要掌握域名擁有者用于加密連接的私鑰。因此，實際應用中，若域名擁有者和域名托管第三方存在信任風險，可采用DNSSEC和本模型結合的方式，同時實現數據來源性驗證和用戶隱私保護。

2.3 系統(tǒng)工作流程

本文模型通過建立信任鏈，實現標識解析過程中全流程加密傳輸。遞歸解析器和根節(jié)點的公鑰通過帶外方式發(fā)布，分別配置到樁解析器和遞歸解析器。假設遞歸解析器無緩存數據，解析數據存儲于二級節(jié)點。一次典型的標識解析流程如圖3所示。

圖3 系統(tǒng)工作流程

系統(tǒng)工作流程具體描述如下：

1)樁解析器使用遞歸解析器的公鑰與其建立加密連接，并發(fā)送查詢請求。

2)遞歸解析器使用根節(jié)點的公鑰與其建立加密連接，并發(fā)送查詢請求。

3)根節(jié)點返回一級節(jié)點的服務地址和公鑰給遞歸解析器。

4)遞歸解析器使用一級節(jié)點的公鑰與其建立加密連接，并發(fā)送查詢請求。

5)一級節(jié)點返回二級節(jié)點的服務地址和公鑰給遞歸解析器。

6)遞歸解析器使用二級節(jié)點的公鑰與其建立加密連接，并發(fā)送查詢請求。

7)二級節(jié)點返回查詢應答結果給遞歸解析器。

8)遞歸解析器返回查詢應答結果給樁解析器。

2.4 與現有安全模型對比分析

目前，域名領域主要的安全模型有基于簽名技術的DNSSEC以及基于加密技術的DoT、DoH等。其中DNSSEC通過數字簽名實施來源性驗證，通過數字摘要連接父子節(jié)點信任鏈，可保障遞歸解析器和權威解析器間的數據安全。但部署DNSSEC后，數據仍然明文傳輸，無法解決隱私保護問題。DoT等安全模型通過樁解析器和遞歸解析器的加密傳輸解決用戶端和遞歸解析器鏈路上的DNS劫持問題，但無法實現各權威節(jié)點的信任傳遞，因此不能覆蓋標識解析全流程。本文模型基于加密傳輸技術，通過加密過程的身份認證實現權威節(jié)點的信任傳遞，可實現標識解析全流程加密傳輸，保障用戶隱私和數據完整性。各模型具體對比如表1所示。

表1 各安全模型技術對比

3 實驗與分析

3.1 實驗方法

為測試不同加密算法、密鑰長度、傳輸數據量等因素對加密傳輸下解析性能的影響及實際可用性，共設計了5組實驗?；舅悸窞榛诓煌膫鬏攨f(xié)議和加密方法，在客戶端與服務端之間建立加密連接，并發(fā)送一定量的數據，計算平均解析時延和服務端CPU使用率并進行安全性分析。

實驗基于TLS協(xié)議對RSA和EC這2種加密算法進行測試。其中，RSA算法測試的密鑰長度分別為512 bit、1024 bit和2048 bit(以下簡稱RSA512、RSA1024和RSA2048)，EC算法測試的密鑰長度分別為160 bit、256 bit和384 bit(以下簡稱EC160、EC256和EC384)。實驗中密鑰對由JDK中的keytool工具生成，客戶端和服務端均為Java程序，JDK版本為JDK1.7.0_80。服務端和客戶端均運行在CentOS release 6.5操作系統(tǒng)上。

3.2 實驗結果與分析

3.2.1 不同加密算法和密鑰長度下解析時延測試(實驗1)

本組實驗基于TLS協(xié)議，使用不同加密算法和密鑰長度，以復用連接和不復用連接的方式與服務端進行5000次通信，計算平均時延。不同加密算法和密鑰長度下基于TLS的平均時延如圖4所示。

圖4 不同加密算法和密鑰長度下基于TLS的平均時延

圖4結果顯示，不復用連接時，平均時延在11.48 ms～21.55 ms之間，復用連接時，平均解析時延顯著降低，相較于不復用連接，下降約98.5%。復用連接情況下，由于連接初始化過程會產生2次RTT(Round-Trip Time)的時延，因此復用連接可以明顯降低時延。此外，握手過程中使用指定的非對稱密鑰進行密鑰協(xié)商，因此解析時延與算法復雜度和密鑰長度呈正相關。復用連接時，由于連接建立后雙方采用對稱加密進行通信，因此握手過程中使用不同的加密算法和密鑰長度對解析時延影響不明顯。

3.2.2 不同響應包大小下解析時延測試(實驗2)

本組實驗基于TLS協(xié)議，分別使用100 B、500 B、1 kB、10 kB和70 kB的報文，以復用連接和不復用連接的方式進行5000次通信，計算平均時延。其中，加密連接使用RSA算法，密鑰長度為1024 bit。不同大小報文基于TLS的平均時延如圖5所示。

圖5 不同大小報文基于TLS的平均時延

與實驗1類似，復用連接相較于不復用連接，解析時延顯著降低，平均約下降95.8%?？傮w上，解析時延與報文大小呈正相關。當報文在10 kB及以下時，報文大小對解析時延影響不明顯，其中復用連接時，平均時延約為0.3 ms，不復用連接時平均時延約為10.46 ms。當報文增長到70 kB時，解析時延出現明顯增長，相較與10 kB報文，復用連接情況下時延增加約161%，不復用連接情況下時延增加約40%。由此可看出，當響應包在70 kB以內時，TLS建立連接消耗的時間遠大于連接建立后數據加密傳輸的時間。

3.2.3 加密傳輸下服務端CPU使用率測試(實驗3)

本組實驗測試了基于TCP協(xié)議和TLS協(xié)議通信時，服務端CPU使用率的變化情況，測試結果見圖6，圖中橫坐標為采集CPU使用率的時間點，t為連接建立后采集的第一份CPU使用率數據。

圖6 TCP和TLS協(xié)議對服務端CPU的占用率

圖6結果顯示，無論是否采用加密連接，服務端的CPU使用率在連接建立時(t時刻)均有顯著增加，其中，TLS加密連接達到約24%，TCP非加密連接達到約17%，TLS加密連接相比TCP非加密連接CPU使用率提高約41%。在連接建立后(t時刻后)，TLS傳輸的CPU平均使用率約為13%，TCP傳輸的CPU平均使用率約為8%，TLS加密傳輸相比TCP非加密傳輸CPU使用率提高約63%。因此，加密連接傳輸相較于非加密連接傳輸將占用更高的CPU資源，實際環(huán)境中，若大量加密連接并發(fā)而造成資源不足，可通過拒絕接受新的加密連接或對部分用戶支持加密連接的方式以節(jié)省資源，保障解析服務正常運行。

3.2.4 現網環(huán)境下DNS查詢時延和報文大小測試(實驗4)

為分析本文模型在實際場景下的可用性，本組實驗測試了現網環(huán)境下DNS解析時延及報文大小。其中DNS查詢的解析時延，通過向1.2.4.8、8.8.8.8、114.114.114.114這3個公共遞歸服務查詢Alexa網站上排名前五的中國網站域名各5000次并計算平均時延得到，DNS報文大小通過向DNS根服務器、.com和.baidu.com的權威服務查詢各自域名的A記錄、NS記錄和DNSKEY記錄得到。

表2 現網環(huán)境DNS遞歸服務查詢時延 單位:ms

從表2可以看出，目前主流的公共遞歸服務平均解析時延均在100 ms以內。其中，由于測試機到1.2.4.8的路由跳數最少，時延最小，為2 ms以內。到8.8.8.8的時延最大，約50 ms～90 ms之間。到114.114.114.114的時延在兩者之間，約16 ms。

表3 現網環(huán)境DNS報文大小情況 單位:B

表3結果顯示，現網環(huán)境大部分DNS報文大小都在1 kB以下。其中，最大的DNS報文是根NS記錄的DNSSEC查詢，非DNSSEC查詢時，常見的A記錄、NS記錄的DNS報文大小一般在200 B以內。

結合前3組實驗情況，并以114.114.114.114解析結果為例，在解析時延方面，采用TLS復用連接方式時延約提升1.8%，不復用連接時延將提升95%。因此，為降低加密傳輸帶來的時延提升，在實際應用中，應盡可能復用已建立的鏈接，降低加密傳輸所帶來的時延和服務器的處理壓力，RFC1035也建議服務端在連接空閑2分鐘以上后再將連接關閉。同時，客戶端應該將連接數量最小化，通過復用一個活躍的加密連接，在客戶端和服務端之間進行多次通信，以有效降低時延[23]。

在報文大小方面，實驗2結果顯示，當報文在10 kB以下時，解析時延變化不明顯，以TLS為例，復用連接時，時延增加約0.3 ms。目前現網環(huán)境DNS報文大小大部分小于1 kB，因此該因素對解析時延無顯著影響。

3.2.5 模型安全性分析(實驗5)

本組實驗通過搭建2級權威節(jié)點解析器(10.192.195.17和10.192.195.21)及遞歸解析器(218.241.111.162)，對模型信任傳遞機制的安全性進行驗證和分析。結果如圖7和圖8所示，從圖中結果可知，遞歸解析器從初始狀態(tài)開始，通過查詢學習到各級權威節(jié)點的證書信息，實現信任傳遞，并全程通過加密方式傳送數據，保障了數據的私密性和完整性。

圖7 根服務器與下級節(jié)點的信任傳遞過程

圖8 本文模型下加密傳輸的解析結果

本文模型依賴加密連接過程的身份認證來實現信任傳遞，因此保障證書的安全非常關鍵。在證書發(fā)布方面，由于遞歸服務器和根服務器分別是用戶和遞歸服務器的查詢起點，因此它們的證書需通過帶外方式發(fā)布。實際應用中，可采用加密傳輸、官方發(fā)布等類似DNS根區(qū)發(fā)布密鑰的方式，保障查詢起點的安全。在證書密鑰方面，由于現代計算機計算能力不斷增強，為防止密鑰被暴力破解，參考DNSSEC相關部署經驗，推薦使用的RSA密鑰長度應不低于1024 bit，EC密鑰長度應不低于160 bit，同時應定期更換密鑰，保障密鑰安全。

4 結束語

本文提出的基于加密通信的標識解析模型，實現了標識系統(tǒng)各節(jié)點在加密方式下的信任傳遞，保障了標識解析全流程下用戶隱私，同時由于數據加密傳輸，防止了數據被篡改，保障了數據傳輸安全。與現有的技術相比，本文模型具有一定的技術優(yōu)勢，但也存在一定的局限。與DNSSEC不同，本文設計的模型依賴標識解析服務提供方的信任傳遞，由于缺乏數字簽名，不能實現類似DNSSEC的來源性驗證。對于實際應用較復雜的場景，如標識擁有方與解析服務提供商存在信任風險時，可采用數字簽名與本文模型結合的方式，進一步加強數據安全的保護。同時，由于全流程加密傳輸，對于網絡流量監(jiān)測分析、惡意流量監(jiān)管等也提出了新的挑戰(zhàn)，需要進一步研究。