DNS通信協(xié)議是如何保護(hù)隱私的

1、 dns通信協(xié)議是如何保護(hù)隱私的 域名系統(tǒng)（dns）是互聯(lián)網(wǎng)基礎(chǔ)服務(wù)，是互聯(lián)網(wǎng)訪問的重要入口，域名隱私保護(hù)是 dns安全的研究熱點(diǎn)。本文提出了一種基于用戶數(shù)據(jù)報(bào)協(xié)議的dns傳輸中用戶隱私保護(hù)的加密方法：dnsdea。該方法采用pki加密體系與dns協(xié)議相融合，不僅解決了域名隱私保護(hù)問題，而且與傳統(tǒng)dns體系相兼容，保持了dns系統(tǒng)的簡單、高效的技術(shù)特點(diǎn)。域名系統(tǒng)（domain name system，dns）是互聯(lián)網(wǎng)的重要基礎(chǔ)服務(wù)之一，主要通過域名和互聯(lián)網(wǎng)協(xié)議地址（ip）等互聯(lián)網(wǎng)基礎(chǔ)資源之間的映射與轉(zhuǎn)換，實(shí)現(xiàn)標(biāo)識和定位互聯(lián)網(wǎng)上服務(wù)器和服務(wù)入口。dns是一個(gè)相對成熟的全球性分布式數(shù)據(jù)庫，為互聯(lián)網(wǎng)

2、提供高效穩(wěn)定的互聯(lián)網(wǎng)標(biāo)識解析服務(wù)。1983 年，mockapetris提出 dns 架構(gòu)，隨后該構(gòu)架在不斷地持續(xù)演進(jìn)和優(yōu)化。在設(shè)計(jì)之初，域名系統(tǒng)在域名協(xié)議方面并沒有考慮完備的安全機(jī)制。1999年，dns安全擴(kuò)展協(xié)議（domain name system security extensions，dnssec）被提出，其能夠有效降低中間人攻擊的風(fēng)險(xiǎn)，保證 dns傳輸數(shù)據(jù)的完整性，從而提升 dns系統(tǒng)的安全服務(wù)能力。2010年，互聯(lián)網(wǎng)域名的根服務(wù)開始部署 dnssec服務(wù)，標(biāo)志著域名服務(wù)開始向安全服務(wù)方向邁進(jìn)，dns 也從一個(gè)簡單的名址轉(zhuǎn)換服務(wù)向復(fù)雜的、可信的解析服務(wù)發(fā)展，傳輸層安全協(xié)議dane（d

3、ns-based authentication of named entities）就是基于 dnssec協(xié)議將數(shù)字證書通過 dns服務(wù)進(jìn)行發(fā)布，以確保證書來自特定的證書頒發(fā)機(jī)構(gòu)。隨著互聯(lián)網(wǎng)普及率的不斷提高及其對生產(chǎn)生活的不斷滲透，人們已經(jīng)對互聯(lián)網(wǎng)產(chǎn)生了越來越強(qiáng)的依賴性，當(dāng)前的互聯(lián)網(wǎng)已不僅是獲取和分享信息的途徑，而且已成為大多數(shù)傳統(tǒng)行業(yè)業(yè)務(wù)系統(tǒng)的基礎(chǔ)載體，因此隱私問題已經(jīng)成為互聯(lián)網(wǎng)亟待解決的一個(gè)重要問題。dns 主要采用用戶數(shù)據(jù)報(bào)協(xié)議（user datagram protocol，udp）協(xié)議明文傳輸方式進(jìn)行名址轉(zhuǎn)換，雖然dnssec協(xié)議提升了數(shù)據(jù)篡改難度，但是依然采用明文方式提供解析服務(wù)。作

4、為互聯(lián)網(wǎng)基礎(chǔ)服務(wù)，dns 對于用戶隱私保護(hù)依然表現(xiàn)出了脆弱性。目前 dns 有關(guān)安全的命題被真正解決得還較少，而其中的隱私問題也已成為行業(yè)關(guān)注的焦點(diǎn)問題并逐漸得到重視。一方面，行業(yè)內(nèi)采用查詢最小化（query minimization）方法降低隱私竊取風(fēng)險(xiǎn)，使用數(shù)據(jù)最小化（data minimization）原理減少 dns權(quán)威服務(wù)收集個(gè)人隱私信息;另一方面，針對 dns解析服務(wù)過程中隱私泄露的問題，國際組織internet engineering task force（ietf）于2014年專門成立 the dns private exchange（dprive）工作組討論并制定 dns 隱

5、私保護(hù)協(xié)議，希望采用數(shù)據(jù)加密傳輸?shù)姆绞綄?shí)現(xiàn) dns隱私保護(hù)?；诖吮尘埃疚奶岢鲆环N基于udp的dns傳輸中用戶隱私保護(hù)的加密方法。研究現(xiàn)狀當(dāng)前，絕大多數(shù) dns 服務(wù)和終端之間的數(shù)據(jù)交換（主要包含請求和反饋）采用明文、非加密的方式進(jìn)行，這將導(dǎo)致用戶隱私暴露在互聯(lián)網(wǎng)通信中，其隱私方面的脆弱性將會被黑客所利用，例如黑客可以收集用戶的訪問痕跡（查詢時(shí)間、訪問內(nèi)容、用戶ip地址等）等信息分析用戶習(xí)慣等。針對這個(gè)問題，目前主要有以下兩種方法保護(hù)dns查詢過程中的用戶隱私。dns數(shù)據(jù)報(bào)文加密dempsky 提出了 dnscurve 方法，該方法基于現(xiàn)有 dns 體系架構(gòu)，使用curve25519 在客戶

6、端和服務(wù)器端交換密鑰以及提供認(rèn)證和數(shù)據(jù)加密。服務(wù)端的公鑰存放在“ns”記錄中發(fā)送給客戶端，因此使用 dnscurve加密dns報(bào)文并不會帶來額外查詢延遲。dnscrypt是dnscurve比較有名的一個(gè)實(shí)現(xiàn)，已在 opendns的服務(wù)上得到廣泛部署，用來解決終端用戶的隱私保護(hù)問題。類似的confidentialdns也使用了 dns的擴(kuò)展機(jī)制為 dns協(xié)議增加加密功能。它提出一種新的資源記錄類型“encrypt”來傳送 dns服務(wù)器的公鑰到客戶端。然后客戶端使用服務(wù)器公鑰加密 dns 查詢請求，以及用來加密 dns響應(yīng)的客戶端公鑰，從而實(shí)現(xiàn)對 dns請求和反饋數(shù)據(jù)進(jìn)行加密保護(hù)。這兩種方案雖然能

7、有效解決dns 明文傳輸所帶來的脆弱性問題，但是需要在dns通信兩端都部署安裝插件（或升級解析軟件）實(shí)現(xiàn)dns通信從明文到密文的目標(biāo)，推廣成本較大，所以目前使用并不廣泛。dns通信鏈路加密tls（transport layer security）是一種為網(wǎng)絡(luò)通信提供數(shù)據(jù)保密以及完整性的安全協(xié)議，它在傳輸層對網(wǎng)絡(luò)連接進(jìn)行加密。目前 tls 最常見的一種應(yīng)用是https協(xié)議，它使用公鑰加密對網(wǎng)站進(jìn)行認(rèn)證，同時(shí)使用對稱加密對數(shù)據(jù)傳輸進(jìn)行加密。tls需要 tcp協(xié)議來保證信道的可靠傳輸，不能直接用來加密保護(hù) udp協(xié)議的數(shù)據(jù)，如果 dns希望使用 tls加密保護(hù)數(shù)據(jù)，就必須使用 tcp協(xié)議。然而現(xiàn)狀是

8、絕大部分的 dns查詢使用 udp協(xié)議，切換為 tcp協(xié)議是一個(gè)長期的過程，并且代價(jià)巨大。因此，就現(xiàn)階段來說，dns-over-tls并不是一個(gè)可行的隱私保護(hù)方案。dtls（datagram transport layer security）數(shù)據(jù)包傳輸層安全協(xié)議是在tls架構(gòu)上提出的一種擴(kuò)展，能夠支持 udp 協(xié)議。dtls 使得直接加密 udp 協(xié)議的 dns 查詢報(bào)文變得可行。ietf草案提出的dns-over-dtls詳細(xì)描述了如何使用dtls技術(shù)加密dns報(bào)文。dns-over-tls 和 dns-over-dtls 使用互聯(lián)網(wǎng)標(biāo)準(zhǔn)協(xié)議 tls 和 dtls 來實(shí)現(xiàn) dns 密文通信。

9、這兩種方法都是采用 tls 協(xié)議進(jìn)行 dns 改進(jìn)，但該方法需要在通信之前需要建立握手、認(rèn)證等一系列復(fù)雜網(wǎng)絡(luò)通信才能實(shí)現(xiàn)，對于訪問量巨大、開銷相對較小的 dns服務(wù)提出了較高的網(wǎng)絡(luò)開銷和性能要求。上述兩種方法對于延遲敏感、高吞吐量的互聯(lián)網(wǎng)基礎(chǔ)服務(wù)dns來說，都帶來了較大挑戰(zhàn)。dns密文通信方法提出了一種新的 dns加密通信方法dnsdea（dns data encryption algorithm），該方法在現(xiàn)有 dns架構(gòu)和報(bào)文格式下采用非對稱加密算法的密文方式通信。通過dns查詢傳輸客戶端的公鑰，以降低基于tls等方法建立鏈接的開銷，減低查詢延時(shí)。同時(shí)，利用其無狀態(tài)特性提高服務(wù)端的并發(fā)性。

10、報(bào)文結(jié)構(gòu)1）加密標(biāo)記位。為標(biāo)記一個(gè) dns 報(bào)文是否為加密報(bào)文，將 dns 報(bào)文頭部后的第一個(gè)字節(jié)定位為加密標(biāo)記位。對于一個(gè)正常的未加密 dns 報(bào)文，該字節(jié)表示查詢域名第一段的長度，按照互聯(lián)網(wǎng)協(xié)議標(biāo)準(zhǔn)（request for comments，rfc），長度應(yīng)小于 64。將該字節(jié)拓展為加密標(biāo)記位，若該字節(jié)小于 64，表示 dns報(bào)文為非加密報(bào)文，若大于64，表示該報(bào)文為加密報(bào)文。2）密鑰格式。dnsdea 采用非對稱加密方法，在 dns 終端和dns 服務(wù)端分別獨(dú)立生成通信密鑰對（含公鑰和私鑰）。dns 服務(wù)端的公鑰通過現(xiàn)有的證書頒發(fā)架構(gòu)（certificate authority infr

11、astructure）發(fā)布，使用該 dns 服務(wù)端的客戶需手動(dòng)配置該公鑰。dns客戶端使用的密鑰在查詢過沖中臨時(shí)生成。考慮到查詢效率等因素，dns客戶端密鑰在一段時(shí)間內(nèi)可重復(fù)使用。客戶端的公鑰由客戶端在dns 報(bào)文的附加段以edns0 格式添加，通過 dns 查詢發(fā)送給 dns 服務(wù)端。密鑰的具體內(nèi)容存放在上面的選項(xiàng)數(shù)據(jù)中，其中前兩個(gè)字節(jié)為算法標(biāo)記位，標(biāo)識該密鑰使用的加密算法，之后兩個(gè)字節(jié)為預(yù)留的標(biāo)識位，最后一部分為具體的公鑰數(shù)據(jù)。3）密報(bào)文格式。加密的 dns報(bào)文的頭部與普通的 dns報(bào)文保持一致，頭部后一個(gè)字節(jié)為加密標(biāo)記位。標(biāo)記位后兩個(gè)字節(jié)為加密數(shù)據(jù)的長度，最后一部分為的加密數(shù)據(jù)。加密查詢

12、方法使用 dnsdea 方法時(shí)，dns 終端需要手動(dòng)配置dns服務(wù)端的公鑰。服務(wù)端的公鑰可通過 pki體系進(jìn)行驗(yàn)證。在 dns終端向 dns服務(wù)端發(fā)送查詢請求時(shí)，使用 dns 服務(wù)端的公鑰對請求資源記錄（rrset）進(jìn)行加密，將dns終端的公鑰制作成rrset并使用dns服務(wù)端的公鑰將其加密，生成 dns 報(bào)文格式數(shù)據(jù)，傳輸給dns服務(wù)端。dns 終端將按照 dns 協(xié)議要求，將生成的 dns 查詢報(bào)文發(fā)送給 dns 服務(wù)端，dns服務(wù)端使用自身私鑰進(jìn)行解密還原待查詢的域名記錄和 dns終端的公鑰信息，按照 dns查詢邏輯尋找查詢結(jié)果，使用還原出來的dns終端公鑰對查詢結(jié)果進(jìn)行加密，發(fā)送給dn

13、s終端。dns 終端接收到應(yīng)答報(bào)文后，使用其私鑰信息將應(yīng)答報(bào)文的應(yīng)答資源記錄（rrset）進(jìn)行解密，并按照dns協(xié)議進(jìn)行處理。以 查詢?yōu)槔?，?shí)現(xiàn)加密查詢方法，主要分以下步驟：（1）服務(wù)端通過 pki發(fā)布公鑰，客戶端手動(dòng)配置服務(wù)端公鑰;（2）客戶端生成密鑰對;（3）客戶端構(gòu)造 的查詢包，將客戶端的公鑰添加在查詢包的附加段，并用服務(wù)端公鑰加密后，將查詢包發(fā)送給服務(wù)端;（4）服務(wù)端收到加密的查詢包，使用服務(wù)端私鑰解密，獲取 dns查詢內(nèi)容和客戶端公鑰;（5）服務(wù)端構(gòu)造的應(yīng)答包，并用客戶端的公鑰加密后，將應(yīng)答包發(fā)送給客戶端;（6）客戶端收到加密的應(yīng)答包，使用客戶端私鑰解密，獲得的應(yīng)答內(nèi)容。實(shí)驗(yàn)及分析為

14、測試 dnsdea 的可行性，進(jìn)行了相關(guān)實(shí)驗(yàn)，對dnsdea 和基于 tls、dtls 加密方法的 dns 查詢進(jìn)行對比，以驗(yàn)證dnsdea 的可行性及相對于目前較流行加密方法的低延遲優(yōu)勢。實(shí)驗(yàn)方法由于 dns 查詢主要通過 udp 傳輸，因此實(shí)驗(yàn)主要關(guān)注 dnsdea 和基于 dtls 加密方法下 dns 查詢包延遲。實(shí)驗(yàn)分別測試了兩種加密方法使用rsa和ecc算法情況下不同大小數(shù)據(jù)包的性能表現(xiàn)，通過發(fā)起多次dns查詢?nèi)∑骄?，?jì)算各方法下dns查詢時(shí)延，比較兩種方法在dns加密使用上的特點(diǎn)。實(shí)驗(yàn)使用openssl-0.9.8 和crypto+5.6.5 加密庫實(shí)現(xiàn) rsa和 ecdsa加密

15、，通過編程模擬了兩種加密方法下dns服務(wù)端和客戶端的軟件行為。客戶端dns查詢均通過腳本定時(shí)循環(huán)調(diào)用實(shí)現(xiàn)，因此基于 dtls加密的查詢每次觸發(fā)新的 dtls連接，未使用歷史會話。實(shí)驗(yàn)運(yùn)行環(huán)境為centos 5.7，服務(wù)端和客戶端分別部署在北京同城的不同節(jié)點(diǎn)。實(shí)驗(yàn)結(jié)果與分析1）固定通信字節(jié)時(shí)延對比。采用10 bit的通信數(shù)據(jù)，利用不同強(qiáng)度的密鑰進(jìn)行測試。從實(shí)驗(yàn)結(jié)果來看，在密鑰長度相等的情況下，基于dtls 加密的 dns 查詢由于在建立連接的過程中密鑰協(xié)商耗時(shí)較大，dns 查詢整體延時(shí)大于 dnsdea 方法下dns延時(shí)。在rsa加密算法下，加密強(qiáng)度越小，密鑰越短，與 dtls方法比較，dnsd

16、ea性能是 dtls方法的2.79倍（定義加速比為dtls方法與dnsdea時(shí)延之比，其比率越高則說明 dnsdea 時(shí)延越低，速度越快）;隨著rsa密鑰長度的增長到2048 bit時(shí)，由于dnsdea需要將客戶端的密鑰加密后，通過 dns 報(bào)文傳送給服務(wù)端，加密耗時(shí)明顯增長，但總時(shí)延仍低于 dtls 加密方法。使用 ecdsa 加密算法情況下，密鑰長度為 112、160、256 bit時(shí)，dnsdea對密鑰加密的開銷小于dtls密鑰協(xié)商的通信開銷，因此總體網(wǎng)絡(luò)延時(shí)優(yōu)于 dtls方法，但隨著加密強(qiáng)度增加到521bit時(shí)，dnsdea對密鑰本身加密的開銷顯著增長，明顯大于 dtls密鑰協(xié)商的通信

17、開銷，造成加密后的 dns 查詢時(shí)延急劇增長，在ecdsa 512下，性能低于dtls方法。2）固定密鑰長度時(shí)延對比。使用rsa算法，選取密鑰長度為1024位，測試了不同長度的dns報(bào)文在dnsdea、dtls方法的時(shí)延情況。由于 dtls在密鑰協(xié)商成功后，采用對稱密鑰加密數(shù)據(jù)，因此隨著 dns報(bào)文的加大，基于 dtls 的 dns加密方法時(shí)延增長不明顯，而 dnsdea 在 dns 報(bào)文較大時(shí)，其傳輸時(shí)延明顯增長。實(shí)驗(yàn)可以看出，在 1024 位密鑰加密條件下，采用dnsdea 傳輸時(shí)延整體明顯低于基于dtls 的 dns 加密方法。綜上所述，在密鑰長度和傳輸報(bào)文較小時(shí)，dnsdea時(shí)延明顯低于 dtls方法;基于dtls加密的方法，由于在連接建立后，雙方采用對稱密鑰加密，其耗時(shí)的增長幅度要小于dnsdea;由于多數(shù) dns 報(bào)文的大小一般都在 200byte 以內(nèi)，因此相較于 dtls 方法，dnsdea 可以明顯降低 dns 加密傳輸時(shí)延。此外，dnsdea 基于 dns傳輸，其無狀態(tài)的特性也可以明顯提升服務(wù)端的并發(fā)性。隨著互聯(lián)網(wǎng)個(gè)人隱私問題得到更多人的關(guān)注，dns隱私泄露問題將會越發(fā)突出。針對dns個(gè)人隱私問題的現(xiàn)有技術(shù)進(jìn)行分析，在現(xiàn)有技術(shù)解決方法基礎(chǔ)上提出了一種新的dns加密通信方法：dnsdea。與傳統(tǒng)方法相比，該方法在現(xiàn)