如何提升SMTP郵件的安全性？從而不被黑客竊聽

簡單郵件傳輸協議（SMTP）用於在郵件服務器之間進行郵件傳輸，而且傳統上是不安全的，所以容易被黑客竊聽。命名實體的基於DNS的認證（國家統計局）用於SMTP提供了郵件傳輸更安全的方法，並逐漸變得愈來愈流行。

在這篇文章中，咱們將討論與SMTP相關的風險以及DANE如何克服這些風險，併爲您提供Internet.nl向那些在實施DANE時照顧郵件服務器的人建議的技巧。

關鍵點：

• 即便安裝了STARTTLS擴展程序，SMTP也有遭受中間人攻擊的風險。
• DANE有助於緩解此類攻擊。有關DANE實施的指南，請參見咱們的操做方法。
• DANE打算在MX域上發佈。所以，若是您使用的是另外一個域的郵件服務器，請確保經過設置一個或多個TLSA記錄來要求該域的管理員支持DANE。

使用STARTTLS的機會性SMTP的風險

默認狀況下，郵件傳輸以純文本格式進行。經過引入STARTTLS擴展，機會安全性已添加到SMTP協議中。這意味着僅當接收郵件服務器請求發送郵件服務器使用加密的傳輸層安全性（TLS）鏈接時，郵件服務器之間的郵件傳輸才受到保護。如圖1所示。

圖1 —儘管與傳統的未加密SMTP鏈接相比，STARTTLS被認爲是一種改進，但仍使電子郵件傳輸容易受到風險的影響。

儘管STARTTLS能夠對郵件傳輸進行加密，可是不會強制執行加密，而且發送郵件服務器不會對接收郵件服務器進行身份驗證。這致使如下風險。

風險1：STRIPTLS /降級攻擊

首先，發送郵件服務器沒法預先肯定接收服務器是否支持加密傳輸。僅在通訊開始以後，發送服務器才能夠從接收服務器支持的功能（在本例中爲STARTTLS）中學習容許加密傳輸的功能。

結果，從一臺郵件服務器到另外一臺郵件服務器的初始鏈接老是開始未加密，從而使其容易受到中間人（MITM）攻擊。若是郵件服務器在SMTP握手期間不提供「 STARTTLS功能」（由於它已被攻擊者剝離），則郵件傳輸將經過未加密的鏈接進行。

圖2-此圖顯示了攻擊者執行MITM攻擊並經過從接收電子郵件服務器中剝離TLS功能來強制創建不安全的鏈接時會發生的狀況。當攻擊者控制發送服務器和接收服務器之間的網絡通訊時，攻擊者可能會經過刪除指示接收服務器支持加密傳輸的信息來降級會話。發送服務器將繼續處理並傳輸未加密的消息，從而使攻擊者能夠看到消息中包含的全部數據。

風險2：將郵件流量轉移到攻擊者的郵件服務器

其次，默認狀況下，郵件服務器不會驗證其餘郵件服務器證書的真實性；接受任何隨機證書。儘管傳統上認爲郵件的傳遞比郵件的安全性更爲重要，但從技術角度來看，尚不清楚要在證書中驗證哪些名稱。

郵件服務器的主機名是經過DNS郵件交換器（MX）查找得到的，可是若是沒有DNSSEC，這些名稱將沒法被信任。結果，攻擊者能夠將任何隨機證書插入鏈接過程。

圖3 —該圖顯示了攻擊者執行MITM攻擊並將其本身的證書插入鏈接過程時會發生什麼。這使攻擊者能夠解密發送和接收郵件服務器之間的通訊。

須要更安全的郵件傳輸

據知名網絡黑客安全專家，東方聯盟創始人郭盛華的研究和事件代表，這些攻擊不是理論上的，而是在平常實踐中發生的，從而致使信息泄漏。咱們須要一種更安全的郵件傳輸方法，以抵消攻擊者推遲和/或篡改郵件傳輸的企圖。這是DANE for SMTP出現的地方。

DANE for SMTP（RFC 7672）使用DNS TLSA資源記錄的存在來安全地發出TLS支持信號，併發布發送郵件服務器能夠成功驗證合法接收郵件服務器的方式。這使安全鏈接能夠抵抗降級和MITM攻擊。

可使用DANE減輕先前描述的帶有機會性TLS的SMTP的風險。如圖4所示，該圖顯示了使用DANE進行郵件傳輸。

圖4-此圖顯示了接收域的郵件服務器的DNS TLSA記錄的存在被髮送郵件服務器解釋爲使用TLS的功能。所以，在與接收域的郵件服務器進行通訊時，能夠強制使用TLS。TLSA記錄中嵌入的指紋可用於驗證接收郵件服務器的證書。所以，在發送方進行DANE驗證的狀況下，具備已發佈TLSA記錄的接收服務器再也不容易受到上述MITM攻擊。

使用DANE時，最好的作法是在證書未經過驗證時，發送郵件服務器停止鏈接並嘗試另外一臺服務器或推遲發送消息。

對於那些想將MTA-STS替代DANE的人來講：這種相對較新的方法彷佛最適合大型雲郵件提供商，沒有像DANE那樣被普遍採用，而且因爲「首先信任」 而被認爲不如DANE安全。使用和緩存，這在RFC 8461中獲得了承認。可是，您能夠在DANE旁邊使用它，由於兩個標準能夠有意地彼此並存。

實施DANE的提示和技巧

若是您打算實施DANE，請參考如下提示和技巧。

入門

首先在您的MX域上發佈DANE記錄，或要求您的郵件提供商這樣作。

下一步是在您的發送郵件服務器上啓用DANE驗證（或要求您的提供商/供應商啓用或實現它）。咱們的方法可能對這些步驟有用。

注意：DANE向後兼容。所以，若是您的郵件服務器支持DANE而鏈接的郵件服務器尚不支持DANE，則一般仍將使用STARTTLS或純文本。

發佈DANE記錄

• DANE打算在MX域上發佈。所以，若是您使用的是另外一個域的郵件服務器，請確保經過設置一個或多個TLSA記錄來要求該域的管理員支持DANE。
• 要注意的另外一件事是DANE依賴於DNSSEC提供的安全性。在實施DANE以前，使您的主域和MX域支持DNSSEC。
• 注意：DNSSEC工具已經很是成熟而且能夠徹底自動化。此外，DNSSEC獲得許多DNS提供商的支持，包括一些較大的參與者。
• 因爲郵件服務器默認狀況下不驗證證書，所以爲郵件服務器購買昂貴的證書對機密性沒有增值或幾乎沒有增值。
• 建議使用證書的公共密鑰來生成TLSA簽名（選擇器類型爲「 1」），而不要使用完整的證書（選擇器類型爲「 0」），由於這樣能夠重複使用密鑰材料。儘管偶爾刷新一下密鑰材料是明智的，可是請注意，使用「向前保密」能夠減小每次使用新密鑰對的須要。
• 僅當接收郵件服務器提供完整的證書鏈時，頒發者證書（使用類型'2'）纔有效。
• 確保TLSA記錄的生存時間（TTL）不過高。這樣能夠在出現問題時相對快速地應用更改。建議在30分鐘（1,800秒）和1小時（3,600秒）之間使用TTL。
• TLSA記錄標識證書。若是證書被新證書替換，則相關的TLSA記錄也須要及時更新。不然會出現不匹配，驗證將失敗，而且DANE感知的服務器不會將消息發送到接收者的域。DANE容許您發佈多個TLSA記錄來解決此問題。經過使用多個TLSA記錄，您能夠建立過渡方案。
• 實施對DANE記錄有效性的監控。

驗證DANE記錄

• 愈來愈多的郵件服務器軟件（如Postfix，Exim，Cloudmark，Halon，Cisco和PowerMTA）支持DANE驗證。若是您使用的是此類軟件，則能夠啓用DANE驗證。
• 確保注意發送郵件服務器的日誌，以查看哪些域未經過DANE驗證。 
• 某些軟件容許測試模式。這意味着DANE驗證已完成並記錄下來，但若是DANE驗證失敗，則沒有交付的後果。

歡迎轉載分享