柏宗超, 姚健康, 孔 寧

1(中國科學(xué)院 計算機網(wǎng)絡(luò)信息中心, 北京 100190)

2(中國互聯(lián)網(wǎng)絡(luò)信息中心, 北京 100190)

3(中國科學(xué)院大學(xué), 北京 100049)

電子郵件是當(dāng)前網(wǎng)絡(luò)辦公中最重要的溝通工具之一, 其傳輸?shù)臄?shù)據(jù)通常是用戶的私人通信信息、密碼恢復(fù)確認(rèn)信息以及公司內(nèi)部和公司間的極具價值的數(shù)據(jù). 電子郵件也是發(fā)起有針對性的網(wǎng)絡(luò)攻擊的首選渠道, 一半以上的電子郵件(53%)屬于垃圾郵件, 越來越多的垃圾郵件包含惡意軟件, 其比例在2016年顯著上升, 電子郵件已經(jīng)一躍成為惡意軟件傳播的主要媒介[1].當(dāng)今, 伴隨著垃圾郵件的泛濫以及社會工程手段的加強, 很難判斷一封電子郵件是否具有欺詐性.

電子郵件系統(tǒng)的基礎(chǔ)是簡單郵件傳輸協(xié)議(Simple Mail Transfer Protocol, SMTP), SMTP 是發(fā)送和中繼電子郵件的互聯(lián)網(wǎng)標(biāo)準(zhǔn)[2,3]. 但是, 正如1981年最初設(shè)想的, SMTP不支持郵件加密、完整性校驗和驗證發(fā)件人身份. 由于這些缺陷, 發(fā)送方電子郵件信息可能會被網(wǎng)絡(luò)傳輸中的監(jiān)聽者截取流量讀取消息內(nèi)容導(dǎo)致隱私泄漏, 也可能遭受中間人攻擊(Man-in-the-Middle attack, MitM)導(dǎo)致郵件消息篡改, 帶來網(wǎng)絡(luò)釣魚攻擊.為了解決這些安全問題應(yīng)對日益復(fù)雜的網(wǎng)絡(luò)環(huán)境, 郵件社區(qū)開發(fā)了諸多電子郵件的擴展協(xié)議, 例如STARTTLS, S/MIME, SPF, DKIM 和 DMARC 等協(xié)議.當(dāng)前的郵件服務(wù)廠商大都也是采用以上擴展協(xié)議的一種或幾種組合, 輔以應(yīng)用防火墻、貝葉斯垃圾郵件過濾器等技術(shù), 來彌補電子郵件存在的安全缺陷.

但是需要注意的是, 以上郵件協(xié)議本身仍存在安全及部署問題, 這有但不限于缺乏針對終端用戶的全球可擴展的密鑰分發(fā)和撤銷機制、當(dāng)前郵件安全解決方案過于復(fù)雜以及自動化部署執(zhí)行方案缺失等原因.比如, 互聯(lián)網(wǎng)工程任務(wù)組IETF在1999年就已經(jīng)發(fā)布了針對終端用戶安全的S/MIME協(xié)議, 但是直到2017年, 該協(xié)議也未能在全球郵件服務(wù)器中大規(guī)模部署.

為了解決當(dāng)前郵件系統(tǒng)中存在的安全及部署問題,IETF在近年發(fā)布了基于域名系統(tǒng)的域名實體認(rèn)證協(xié)議 (DNS-based Authentication of Named Entities,DANE)及基于DANE的諸多擴展協(xié)議來提升電子郵件的機密性及安全性[4–6]. 簡而言之, 這些通過 DANE改進(jìn)的協(xié)議基于域名系統(tǒng)(Domain Name System,DNS)和域名系統(tǒng)安全擴展 (DNS Security Extensions,DNSSEC)的現(xiàn)有基礎(chǔ)架構(gòu), 創(chuàng)建終端用戶使用的X.509證書的安全全局存儲庫以及驗證電子郵件服務(wù)器的加密憑據(jù), 彌補了當(dāng)前電子郵件系統(tǒng)中存在的諸多不足.

截至目前, 國內(nèi)對電子郵件系統(tǒng)及其協(xié)議的研究較少, 本文創(chuàng)新性地從郵件加密和驗證兩個方面系統(tǒng)地梳理了當(dāng)前電子郵件系統(tǒng)所使用的協(xié)議及其架構(gòu)演進(jìn), 分析了DANE及基于DANE對當(dāng)前普遍采用的郵件協(xié)議的改進(jìn), 最后展望了未來基于DANE的電子郵件系統(tǒng)發(fā)展, 以期為未來研究提供有益的啟發(fā)和借鑒.

本文剩余部分的組織結(jié)構(gòu)如下: 第1節(jié)和第2節(jié)分別從電子郵件加密和驗證角度介紹當(dāng)前電子郵件系統(tǒng)的加密和驗證機制. 第3節(jié)闡述IETF近年提出的DANE、其對當(dāng)前郵件加密和驗證協(xié)議的改進(jìn)和不足以及基于DANE的安全郵件系統(tǒng)架構(gòu). 第4節(jié)總結(jié)和展望.

1 電子郵件的機密性

為了保證電子郵件的機密性防止數(shù)據(jù)監(jiān)聽后明文讀取, 通常是從郵件傳輸通道和郵件消息兩個角度考慮數(shù)據(jù)加密.

1.1 郵件在傳輸過程中的機密性

為了保證郵件在傳輸過程中的機密性, IETF在1999年發(fā)布了通過傳輸層安全協(xié)議(Transport Layer Security, TLS)來提升SMTP安全性的互聯(lián)網(wǎng)標(biāo)準(zhǔn)[7].但是, 原始的SMTP協(xié)議并不兼容TLS協(xié)議, 為了解決這個問題, 一個新的命令(STARTTLS)被添加到協(xié)議中, STARTTLS通過TLS/SSL將SMTP明文通信連接升級為加密連接. 在一個經(jīng)典的STARTTLS會話中,客戶端首先與郵件中繼服務(wù)器協(xié)商進(jìn)行SMTP連接;然后客戶端發(fā)送STARTTLS命令, 該命令啟動標(biāo)準(zhǔn)TLS握手; 最后, 客戶端通過此加密保護信道來發(fā)送郵件內(nèi)容、附件和任何相關(guān)聯(lián)的數(shù)據(jù). 圖1為添加STARTTLS命令后的郵件傳輸?shù)暮喕瘓鼍皥D.

圖1 STARTTLS 隨機加密簡化場景圖

STARTTLS旨在保護與SMTP服務(wù)器之間郵件信息地發(fā)送, 主要是通過TLS加密的方式來防止電子郵件在傳輸過程中信息泄漏. 但是, STARTTLS提供的是隨機加密 (opportunistic encryption), 這與 HTTPS 客戶端的行為不同, HTTPS客戶端嚴(yán)格要求通信雙方都使用TLS協(xié)議. 而如果郵件中繼服務(wù)器不支持或拒絕STARTTLS命令, 那么郵件將會以明文繼續(xù)傳輸(587端口). 使用STARTTLS加密信道雖然防止了郵件在傳輸過程中被監(jiān)聽讀取, 卻不能阻止攻擊者利用STARTTLS的這一特性發(fā)動降級的中間人攻擊(MitM Downgrade Attack)[8].

此外, 即使雙方服務(wù)器協(xié)商使用TLS加密, 發(fā)送方也無法保證收件人郵件服務(wù)器的真實性. 在RFC 3207中并沒有定義接收方如何驗證接收到的加密證書, 而在幾乎所有情況下, 接收方不會驗證接收的證書,這也是一個潛在的威脅.

針對以上問題, 當(dāng)前IETF工作組提出了保護郵件通信安全的一個草案SMTP-STS[9]. 該草案與HSTS(RFC 6797)標(biāo)準(zhǔn)類似, 在 HTTPS 協(xié)議中, 用戶能夠選擇不允許通過不安全的信道, HSTS則允許站點指示給用戶之后的連接必須使用HTTPS. SMTP-STS的原理是讓接收域在其DNS中發(fā)布資源紀(jì)錄, 以明確的URL來發(fā)布其安全策略, 發(fā)件人則使用HTTPS進(jìn)行訪問. 該草案的優(yōu)點在于它在解決STARTTLS以上兩個問題的同時, 定義了規(guī)則、反饋機制及在TLS協(xié)商失敗后采取對應(yīng)的措施, 而且該草案并未規(guī)定使用DNSSEC. 但是, 該草案也有其缺點, 它要求發(fā)送方郵件中繼服務(wù)器 (Mail Transfer Agent, MTA) 必須使用HTTPS來確保安全信道存在, 還可能存在DNS欺騙或者分布式拒絕服務(wù)攻擊, 阻止客戶端查詢這些策略.

SMTP-STS雖然在一定程度上解決了STARTTLS中存在的問題, 但是該協(xié)議仍然是一個針對MTA之間通信的信任機制, 它對端到端的郵件加密和電子簽名沒有任何作用.

1.2 郵件端到端的加密

電子郵件協(xié)議在設(shè)計之初, 僅支持純文本消息的數(shù)據(jù)傳輸(RFC 822). 為了滿足不同類型消息的發(fā)送,IETF在1996年發(fā)布了多用途互聯(lián)網(wǎng)郵件擴展協(xié)議(Multipurpose Internet Mail Extensions, MIME)[10–12],MIME協(xié)議的發(fā)布擴展了SMTP協(xié)議, 使得電子郵件可以支持格式化文本、附加文件、HTML音視頻、應(yīng)用程序和圖片等多種數(shù)據(jù)格式.

為了保證MIME數(shù)據(jù)的機密性、完整性以及來源驗證, IETF在1996年和1999年分別發(fā)布了基于MIME協(xié)議的擴展協(xié)議OpenPGP[13]和S/MIME[14],S/MIME和OpenPGP都使用了公開密鑰加密機制實現(xiàn)電子郵件的數(shù)字簽名和加密. 由于信任鏈以及密鑰管理等方式的不同, S/MIME相對來說具有更廣泛的應(yīng)用場景.

公鑰加密機制為電子郵件用戶提供了一種產(chǎn)生公鑰/私鑰對的方式, 密鑰通常需要被證書簽發(fā)機構(gòu)(Certificate Authority, CA)簽名或者編碼為自簽名證書. 公鑰數(shù)字證書旨在提供給全球的任何個人、組織和機構(gòu), 以便他們可以使用S/MIME來加密要發(fā)送的電子郵件. 在公鑰密碼體制中, 公鑰加密的電子郵件只能被持有該公鑰對應(yīng)的私鑰的接收者解密. 此外, 私鑰還可用于電子郵件的數(shù)字簽名, 因為只有發(fā)件人擁有某一公鑰對應(yīng)的私鑰, 所以該機制能夠確保電子郵件發(fā)件人的真實性及數(shù)據(jù)完整性.

然而, 一個不幸的事實是, 雖然S/MIME協(xié)議采用的信任機制很好, 但是, S/MIME的部署過程過于復(fù)雜.

首先, 生成和安裝S/MIME所使用的加密/簽名密鑰的手動操作步驟非常困難和耗時, 需要通信雙方對公鑰加密體制等密碼學(xué)原理有所了解. 同時, 用戶需要自行保管私鑰. 考慮普通用戶通常會有多個終端設(shè)備和多個電子郵件賬號, 將私鑰從一個終端設(shè)備傳輸?shù)搅硪粋€設(shè)備, 這對大多數(shù)用戶來說是不可能的. 因此,大多數(shù)用戶根本不會使用S/MIME.

其次, 假設(shè)用戶掌握了密鑰安裝和管理的技術(shù), 下一步是關(guān)于分發(fā)和管理公鑰數(shù)字證書. 到目前為止, 沒有一個可以用于發(fā)布和檢索個人公鑰的全局密鑰存儲庫. 相反, 通常是使用S/MIME加密的用戶通過向收件人發(fā)送帶有數(shù)字簽名的電子郵件或者通過電話等方式手動分發(fā)密鑰到收件人. OpenPGP是通過“密鑰交換方”和一組有限的密鑰交換服務(wù)器使用信賴網(wǎng)絡(luò)(Web of Trust, WoT)分發(fā)密鑰. S/MIME 和 OpenPGP 都不具有很好的擴展性, 郵件服務(wù)器廠商無法向密鑰未知的客戶發(fā)送加密電子郵件, 這限制了用戶對該加密協(xié)議的使用.

另一個操作問題是偽造數(shù)字證書. 某些可信任的權(quán)威CA可能會由于失誤或者其它原因簽發(fā)偽造的簽名證書, 而通常情況下, 收件人又不會檢查電子郵件證書的正確性, 只要證書存在, 通常會認(rèn)為它是有效的.與假冒證書相關(guān)的問題是類似域名中存在的“變體域名”問題, 也就是注冊高度相似的極具欺騙性的域名,比如域名“icbc.cn”和“1cbc.cn”. 在電子郵件系統(tǒng)的中,當(dāng)這些變體域名申請了偽造的數(shù)字簽名后, 由于普通用戶通常不具備足夠的鑒別能力, 可能導(dǎo)致被欺騙. 比如來自“alice@examp1e.cn”(‘1’為數(shù)字 1)的欺詐郵件可能會被誤認(rèn)為合法的“alice.example.cn”. 而此時如果能夠有一個全局管理證書的存儲庫, 如DNS, 通過向該存儲庫查詢則可以鑒別真?zhèn)? 從而避免使用到惡意證書.

同時, S/MIME協(xié)議本身是沒有制定規(guī)則和反饋機制的, 當(dāng)由于一些未知原因?qū)е戮芙^接受S/MIME加密或簽名的電子郵件時, 無法提供故障反饋.

2 郵件身份驗證

雖然STARTTLS和SMTP-STS保證了郵件在傳輸過程中的加密, 防止遭受竊聽讀取, 但是其仍無法解決發(fā)件方身份偽造、消息篡改等問題. 當(dāng)前的電子郵件系統(tǒng)主要是通過三種基于DNS來發(fā)布和檢索資源記錄的方式解決這些問題.

2.1 SPF和DKIM

發(fā)件人策略框架 (Sender Policy Framework, SPF)是一種以IP地址認(rèn)證電子郵件發(fā)件人身份的檢測電子郵件欺詐的技術(shù), 是非常高效的垃圾郵件解決方案[15,16].SPF允許組織授權(quán)一系列為其域發(fā)送郵件的主機, 而存儲在DNS中的SPF記錄則是一種TXT資源記錄,用以識別哪些郵件服務(wù)器獲允代表本網(wǎng)域發(fā)送電子郵件. SPF阻止垃圾郵件發(fā)件人發(fā)送假冒本網(wǎng)域中的“發(fā)件人”地址的電子郵件, 收件人通過檢查域名的SPF記錄來確定號稱來自該網(wǎng)域的郵件是否來自授權(quán)的郵件服務(wù)器. 如果是, 就認(rèn)為是一封正常的郵件, 否則會被認(rèn)為是一封偽造的郵件而進(jìn)行退回. SPF還允許組織將其部分或全部SPF策略委托給另一個組織, 通常是將SPF設(shè)置委托給云提供商.

DKIM域名密鑰識別郵件標(biāo)準(zhǔn)(Domain Keys Identified Mail)是一種通過檢查來自某域簽名的郵件標(biāo)頭來判斷消息是否存在欺騙或篡改的檢測電子郵件欺詐技術(shù)[17]. DKIM是利用加密簽名和驗證的原理, 在發(fā)件人發(fā)送郵件時候, 將與域名相關(guān)的私鑰加密的簽名字段插入到消息頭, 收件人收到郵件后通過DNS檢索發(fā)件人的公鑰(DNS TXT記錄), 就可以對簽名進(jìn)行驗證, 判斷發(fā)件人地址及消息的真實性. 需要注意的是,DKIM只能驗證發(fā)件人地址來源的真?zhèn)? 無法辨識郵件內(nèi)容的真實性. 同時, 如果接收到無效或缺少加密簽名的消息, DKIM無法指定收件人采取什么措施. 此外,私鑰簽名是對本域所有外發(fā)郵件進(jìn)行普遍的簽名, 是郵件中繼服務(wù)器對郵件進(jìn)行DKIM簽名而不是真正的郵件發(fā)送人, 這意味著, DKIM并不提供真正的端對端的電子簽名認(rèn)證.

SPF和DKIM中共同存在的問題是缺少有效的策略和反饋機制, 這兩個協(xié)議并未定義如何處理來自聲稱為某域的未經(jīng)身份驗證的電子郵件, 如何處理第三方聲稱托管的某域的未經(jīng)身份驗證的郵件, 如何反饋和統(tǒng)計聲稱是某域的身份認(rèn)證成功或失敗的電子郵件.

2.2 DMARC

DMARC以域名為基礎(chǔ)的郵件認(rèn)證、報告和一致性標(biāo)準(zhǔn) (Domain-based Message Authentication, Reporting,and Conformance)就是用來解決SPF和DKIM中存在的這些問題[18], DMARC的主要用途在于設(shè)置“策略”,這個策略包含接收到來自某個域未通過身份驗證的郵件時應(yīng)執(zhí)行什么操作、該域授權(quán)的第三方提供商發(fā)送了未經(jīng)身份驗證的郵件時該如何處理. DMARC還會讓ISP發(fā)送有關(guān)某個域身份驗證成功或失敗的報告,這些報告將發(fā)送至“rua”(匯總報告)和“ruf”(取證報告)中定義的地址中. 同時, DMARC依靠出站郵件流配置的SPF記錄和DKIM密鑰來確保郵件來源及簽名的完整性, 當(dāng)未通過SPF或DKIM檢查的郵件時便會觸發(fā)DMARC策略. 圖2為基于SPF、DKIM和DAMRC的郵件驗證簡化場景圖.

圖2 郵件驗證簡化場景圖

3 基于DNS的域名實體認(rèn)證協(xié)議DANE

DANE一種將X.509證書綁定到DNS中的機制,可用于存儲自簽名證書或者從CA簽發(fā)的特定X.509證書, 其中, 證書作為DNS資源記錄通過DNSSEC來實現(xiàn)其來源驗證和完整性保護[19–21]. 根據(jù)證書用途的不同, 基于DANE的DNS資源記錄也有所不同: 資源記錄TLSA用于發(fā)布使用TLS加密的證書, 資源記錄OPENPGPKEY和SMIMEA分別用來發(fā)布OpenPGP和S/MIME協(xié)議中使用的證書.

保護公開密鑰防止被篡改是實際公鑰應(yīng)用中一大難題, 公鑰基礎(chǔ)設(shè)施PKI的主要目的就是用來安全、便捷、高效地獲得公鑰, 而IETF發(fā)布DANE協(xié)議的動機之一是解決現(xiàn)有的基于X.509的PKI的問題. 例如, DANE在應(yīng)對欺詐證書、處理證書撤銷、創(chuàng)建可全球發(fā)布和檢索證書的管理機制并允許自簽名證書授權(quán)等方面提供了很好的解決方式.

DNS的層級架構(gòu)創(chuàng)建了授權(quán)機制, DANE基于DNS的授權(quán)機制來實現(xiàn)以上目標(biāo). 在DNS中只有授權(quán)的域所有者才能夠在其DNS域中放置相應(yīng)的資源記錄, 其他未授權(quán)的人都沒有權(quán)限這樣做. 例如, 只有擁有“example.com”域名的公司才可以在該域名的DNS名稱空間中放置資源記錄.

DANE協(xié)議的第一個應(yīng)用是針對Web服務(wù)器中使用的TLS證書的身份驗證, 而目前其在郵箱中的應(yīng)用主要針對以上TLS、S/MIME、OpenPGP和DMARC協(xié)議的改進(jìn).

3.1 基于DANE的TLS

在2.1節(jié)中已經(jīng)闡述了SMTP服務(wù)器在使用STARTTL命令開啟TLS加密傳輸中存在降級的中間人攻擊潛在風(fēng)險, 而基于DANE的隨機TLS加密則可以很好的解決這個問題[5]. 其大致流程圖如圖3所示.

圖3 DANE STARTTLS

在發(fā)出STARTTLS命令之前, 郵件服務(wù)器先發(fā)出DNS查詢請求, 查看接收方服務(wù)器是否存在相關(guān)的DANE TLSA 記錄. 如果記錄存在, 那么使用加密傳輸?shù)腟TARTTLS命令就一定會發(fā)出, 這時如果由于中間人等原因, 導(dǎo)致接收方服務(wù)器拒絕STARTTLS請求或者接收到的證書與DANE TLSA紀(jì)錄不匹配, 郵件服務(wù)器就會中止通信, 并在稍后重新發(fā)送加密傳輸請求.如果接收方DNS服務(wù)器中未部署DANE TLSA, 則繼續(xù)使用隨機TLS加密.

因此, DANE在保證郵件服務(wù)器加密傳輸?shù)耐瑫r,又能驗證接收到的證書的真實性. 同時, 由于TLSA紀(jì)錄存在與否并不影響當(dāng)前郵件系統(tǒng)采用降級的TLS的加密傳輸策略, 所以可以增量部署DANE安全機制.

3.2 基于DANE的S/MIME

盡管基于DANE的隨機TLS加密提供了一種保證數(shù)據(jù)在郵件中繼服務(wù)器之間加密傳輸?shù)臋C制, 在郵件終端用戶端到端的安全和驗證方面卻沒有任何保障:無法獲取終端用戶的數(shù)字簽名, 無法對終端接收方身份驗證以及無法保證電子郵件在到達(dá)接收方郵件服務(wù)器之后仍然加密存儲. 在1.2小節(jié)中闡述了S/MIME協(xié)議可以用來解決這些問題及其自身存在的密鑰管理和分發(fā)問題, 而基于DNSSEC的DANE則可以解決S/MIME的這些問題.

2017年5月31日正式發(fā)布的RFC 8162通過定義SMIMEA資源記錄來擴展DANE協(xié)議. SMIMEA紀(jì)錄與TLSA記錄遵循相同的協(xié)議格式, 但是可以用來存儲單個用戶的證書數(shù)據(jù). 該協(xié)議采用哈希算法將電子郵件地址存儲在SMIMEA資源記錄中, 保證發(fā)送方查詢收件人證書的同時, 提供隱私保護. 該協(xié)議通過使用由DNSSEC保護的DNS系統(tǒng), 利用DNS作為可信任的存儲庫, 實現(xiàn)終端用戶電子郵件證書的身份驗證.

3.3 DANE對DMARC的補充

DMARC為SPF和DKIM定義了一些策略, 提供反饋機制來報告所采取的行為, 旨在防止攻擊者偽造電子郵件的發(fā)件域發(fā)送欺詐郵件, 防止重放攻擊, 確保收件人收到的郵件確實來自聲稱域; 而DANE則可以確保雙方通信信道安全, 能夠讓發(fā)件方確定確實是在與指定的收件人通信, 保證數(shù)據(jù)加密傳輸給特定收件人.

從兩者功能考慮, DMARC和DANE互為補充, 誰也不能取代誰. 為此, IETF為DANE提出了DMRAC的擴展草案[22].

3.4 DANE的不足

當(dāng)然, DANE 也有其“先天不足”之處. 基于 DANE的郵件系統(tǒng)最為外界所詬病的是其需要依靠DNSSEC來對接收到的DNS資源記錄來源進(jìn)行認(rèn)證, 驗證其存在性和數(shù)據(jù)完整性. 畢竟當(dāng)前DNSSEC還未在全網(wǎng)廣泛部署[23], 因此, 會阻礙DANE在全球范圍內(nèi)的部署.

同時, DNSSEC本身也存在一些安全及部署問題[24].如果攻擊者想要對基于DANE的郵件系統(tǒng)發(fā)動攻擊,此時, 可以針對DNSSEC的安全問題發(fā)送攻擊, 一旦攻擊導(dǎo)致DNSSEC無法正常運作, DANE因此也會受到牽連, 從而導(dǎo)致基于DANE的郵件系統(tǒng)癱瘓.

最后, 由于域所有者需要對新添加的SMIMEA資源記錄進(jìn)行管理, 因此可能存在一些管理上的問題, 這加大了管理者管理難度[25].

3.5 基于DANE的郵件系統(tǒng)架構(gòu)

根據(jù)當(dāng)前IETF提出的DANE及其對當(dāng)前郵件協(xié)議的改進(jìn), 本文提出了基于DANE的郵件系統(tǒng)架構(gòu).圖4 展示了基于DANE的郵件系統(tǒng)如何實現(xiàn)端到端的郵件加密、消息完整性鑒定和來源驗證. 其具體流程如下文.

圖4 基于 DANE 的安全郵件系統(tǒng)架構(gòu)

假設(shè)分別位于兩個不同域的Alice和Bob需要使用加密和認(rèn)證的電子郵件進(jìn)行通信, 他們均已經(jīng)獲得了X.509證書. 此時, 如果沒有針對電子郵件證書的全球公共存儲庫, Alice和Bob如何獲得對方所在域的證書？如果針對電子郵件單獨建立一個全球公共存儲卡,則無論是從管理還是花銷上, 其代價都是巨大的. 而DANE通過在DNS中發(fā)布資源記錄則可以相對“輕松”地提供這樣的功能.

Alice使用私鑰對要發(fā)送給Bob的郵件消息進(jìn)行數(shù)字簽名, 這可以直接在其本地終端設(shè)備上使用S/MIME協(xié)議的電子郵件客戶端中完成. 接下來, 為了加密消息, 本地客戶的向DNS進(jìn)行查詢以檢索收件人Bob的公鑰證書, 使用公鑰證書確保只有Bob可以解密郵件, 同時此證書由用戶緩存以備將來再次使用. 簽名和加密的消息之后發(fā)送給Alice所在域的郵件服務(wù)器, 郵件服務(wù)器在發(fā)出郵件之前, 繼續(xù)使用基于DANE的STARTTLS進(jìn)行協(xié)商加密, 保證郵件中繼服務(wù)器之間的加密傳輸. 在最終Bob所在域的郵件服務(wù)器接收郵件之前, receiver域還需要使用DMARC等協(xié)議來確保郵件來源的真實性以及郵件的完整性.

當(dāng)Bob從郵件服務(wù)器接收消息后, 將通過他的私鑰對郵件進(jìn)行解密, 在Bob的終端設(shè)備中執(zhí)行解密操作可確保數(shù)據(jù)在到達(dá)服務(wù)器之后的機密性. 之后Bob需要驗證此消息, 確定該郵件真的是來自sender域的發(fā)件人Alice還是欺詐郵件. 為了確認(rèn)真實性, 郵件客戶端必須檢查數(shù)字簽名的真實性, 此時需要Bob通過執(zhí)行發(fā)送DNS查詢檢索Alice的公鑰證書,用于解密數(shù)字簽名并執(zhí)行數(shù)據(jù)完整性檢查. 如果簽名驗證正確, 則該消息是真實的, 同時確定該郵件在傳輸過程中沒有改變.

4 總結(jié)與展望

當(dāng)前業(yè)界采用的STARTTLS保證郵件傳輸過程中的機密性, SPF、DKIM和DMARC保證郵件來源驗證及完整性鑒別的方式, 在一定程度上解決了電子郵件中的諸多安全問題, 但是面對當(dāng)下垃圾郵件肆虐、網(wǎng)絡(luò)釣魚橫行的網(wǎng)絡(luò)環(huán)境, 這些措施仍舊顯得力不從心.

DANE的出現(xiàn)為解決當(dāng)前電子郵件中加密傳輸存在的降級攻擊、郵件端到端加密等問題提供了一個可行的思路. DANE基于DNS的特性保證了其可以建立一個全球范圍的可擴展的電子郵件證書分發(fā)和管理機制, 為建立全球可信的電子郵件網(wǎng)絡(luò)打下堅實的基礎(chǔ).

當(dāng)前國內(nèi)外基于DANE的研究及部署尚在初期階段, 本文梳理了基于DANE的郵件擴展協(xié)議, 提出了一套以DANE為基礎(chǔ)的郵箱系統(tǒng)架構(gòu), 以期為未來研究及建立一套全球范圍更加安全的的郵件系統(tǒng)提供有益的啟發(fā)和借鑒.