主持人 > 博客 > 管理 > Mail.ru 郵件開始在測試模式下套用 MTA-STS 策略

Mail.ru 郵件開始在測試模式下套用 MTA-STS 策略

Mail.ru 郵件開始在測試模式下套用 MTA-STS 策略

簡而言之，MTA-STS 是一種進一步保護電子郵件在郵件伺服器之間傳輸時免遭攔截（即中間人攻擊，又稱 MitM）的方法。 它部分解決了電子郵件協定的遺留架構問題，並在相對較新的標準 RFC 8461 中進行了描述。Mail.ru 是 RuNet 上第一個實現該標準的主要郵件服務。 並且在剪切下有更詳細的描述。

MTA-STS 解決什麼問題？

從歷史上看，電子郵件協定（SMTP、POP3、IMAP）以明文形式傳輸訊息，這使得在存取通訊通道時等情況下可以攔截訊息。

將信件從一個使用者傳遞給另一個使用者的機制是什麼樣的：

Mail.ru 郵件開始在測試模式下套用 MTA-STS 策略

從歷史上看，所有郵件流通的地方都可能發生中間人攻擊。

RFC 8314 要求在郵件使用者應用程式 (MUA) 和郵件伺服器之間使用 TLS。 如果您的伺服器和您使用的郵件應用程式符合 RFC 8314，那麼您（很大程度上）就消除了使用者和郵件伺服器之間發生中間人攻擊的可能性。

遵循普遍接受的做法（由 RFC 8314 標準化）可以消除使用者附近的攻擊：

Mail.ru 郵件開始在測試模式下套用 MTA-STS 策略

Mail.ru 郵件伺服器甚至在標準被採用之前就遵守了 RFC 8314；事實上，它只是簡單地捕獲了已經接受的實踐，我們不需要配置任何額外的東西。 但是，如果您的郵件伺服器仍然允許使用者使用不安全的協議，請務必實施此標準的建議，因為最有可能的是，至少您的一些用戶使用未加密的郵件，即使您支援它。

郵件用戶端始終與同一組織的相同郵件伺服器一起工作。 並且您可以強制所有使用者以安全方式連接，然後使非安全使用者在技術上無法連接（這正是 RFC 8314 所要求的）。 這有時很困難，但也是可行的。 郵件伺服器之間的流量仍然更加複雜。 伺服器屬於不同的組織，通常以「設定後忘記」模式使用，這使得不可能在不中斷連線的情況下立即切換到安全協定。 SMTP 很早就提供了 STARTTLS 擴展，允許支援加密的伺服器切換到 TLS。 但有能力影響流量的攻擊者可以「刪除」有關支援該命令的信息，並強制伺服器使用純文字協定進行通訊（所謂的降級攻擊）。 基於同樣的原因，STARTTLS 通常不會檢查憑證的有效性（不受信任的憑證可以防止被動攻擊，這並不比以明文形式發送訊息差）。 因此，STARTTLS 只能防止被動竊聽。

當攻擊者有能力主動影響流量時，MTA-STS 部分消除了郵件伺服器之間攔截信件的問題。 如果收件者的網域發布了 MTA-STS 策略，且寄件者的伺服器支援 MTA-STS，則它將僅透過 TLS 連線將電子郵件傳送至該策略定義的伺服器，並且僅驗證伺服器的憑證。

為什麼部分？ 只有當雙方都認真執行此標準時，MTA-STS 才有效，並且 MTA-STS 無法防止攻擊者能夠從公共 CA 之一獲取有效域證書的情況。

MTA-STS 的工作原理

接受者

  1. 使用郵件伺服器上的有效憑證設定 STARTTLS 支援。 
  2. 透過HTTPS發布MTA-STS策略；例如，使用特殊的mta-sts域和特殊的眾所周知的路徑來發布 https://mta-sts.mail.ru/.well-known/mta-sts.txt。 此原則包含有權接收該網域郵件的郵件伺服器 (mx) 清單。
  3. 在 DNS 中發布帶有政策版本的特殊 TXT 記錄 _mta-sts。 當策略變更時，必須更新此條目（這表示傳送者重新查詢策略）。 例如， _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

發件人

寄件者請求 _mta-sts DNS 記錄，如果可用，則透過 HTTPS 發出政策請求（檢查憑證）。 產生的策略會被快取（以防攻擊者阻止對其的存取或欺騙 DNS 記錄）。

發送郵件時，會檢查：

  • 郵件投遞到的伺服器在策略中；
  • 伺服器使用 TLS (STARTTLS) 接受郵件並具有有效的憑證。

MTA-STS 的優點

MTA-STS 使用大多數組織已實施的技術（SMTP+STARTTLS、HTTPS、DNS）。 對於接收方的實施，不需要對該標準的特殊軟體支援。

MTA-STS 的缺點

需監控Web和郵件伺服器憑證的有效性、名稱的對應關係，並及時更新。 證書出現問題將導致郵件無法投遞。

在傳送者一側，需要支援 MTA-STS 策略的 MTA；目前，MTA 中不支援開箱即用的 MTA-STS。

MTA-STS 使用受信任的根 CA 清單。

MTA-STS 無法防範攻擊者使用有效憑證的攻擊。 在大多數情況下，靠近伺服器的 MitM 意味著能夠頒發憑證。 可以使用憑證透明度來偵測此類攻擊。 因此，總的來說，MTA-STS 減輕了但並沒有完全消除流量攔截的可能性。

最後兩點使得 MTA-STS 的安全性低於 SMTP 的競爭 DANE 標準 (RFC 7672)，但技術上更可靠，即對於MTA-STS，由於標準實施引起的技術問題而導致信件無法投遞的可能性很小。

競爭標準 - DANE

DANE 使用 DNSSEC 發布證書訊息，不需要信任外部證書頒發機構，安全得多。 但根據多年使用的統計數據，DNSSEC 的使用更常導致技術故障（儘管 DNSSEC 的可靠性及其技術支援總體呈現正面趨勢）。 為了在接收方的 SMTP 中實現 DANE，DNS 區域的 DNSSEC 的存在是強制性的，並且對 NSEC/NSEC3 的正確支援對於 DANE 至關重要，這在 DNSSEC 中存在系統性問題。

如果 DNSSEC 配置不正確，如果發送方支援 DANE，即使接收方對此一無所知，也可能會導致郵件傳送失敗。 因此，儘管DANE是一個較舊且更安全的標準，並且已經在發送端的一些伺服器軟體中得到支持，但事實上它的滲透率仍然微不足道，許多組織由於需要實施DNSSEC而沒有準備好實施它，在在該標準存在的這些年裡，這大大減慢了DANE 的實施速度。

DANE和MTA-STS互不衝突，可以一起使用。

Mail.ru Mail 中的 MTA-STS 支援有什麼用？

Mail.ru 為所有主要網域發布 MTA-STS 策略已經有一段時間了。 我們目前正在實施該標準的客戶端部分。 在撰寫本文時，策略以非阻塞模式套用（如果投遞被政策阻止，信件將透過「備用」伺服器投遞而不套用原則），然後一小部分將強制使用阻塞模式的傳出SMTP 流量，逐漸為100 % 的流量提供支援策略的執行。

還有誰支持該標準？

到目前為止，MTA-STS 策略發布了大約 0.05% 的活動域，但儘管如此，它們已經保護了大量的郵件流量，因為該標準得到了主要參與者的支持——Google、康卡斯特和部分威瑞森（AOL、雅虎）。 許多其他郵政服務已宣布將在不久的將來實施對該標準的支持。

這將如何影響我？

除非您的網域發布了 MTA-STS 策略，否則不會。 如果您發布該策略，您的郵件伺服器使用者的電子郵件將得到更好的保護，免於攔截。

如何實施 MTA-STS？

接收者的 MTA-STS 支持

透過 HTTPS 發布策略並在 DNS 中記錄就足夠了，為 MTA 中的 STARTTLS 配置來自受信任 CA 之一的有效憑證（可以進行加密）（所有現代 MTA 都支援 STARTTLS），無需來自需要 MTA。

一步一步來看，它看起來像這樣：

  1. 在您使用的 MTA（postfix、exim、sendmail、Microsoft Exchange 等）中設定 STARTTLS。
  2. 確保您使用有效的憑證（由受信任的 CA 頒發，未過期，憑證的主題與為您的網域傳送郵件的 MX 記錄相符）。
  3. 設定 TLS-RPT 記錄，透過此記錄傳送策略應用程式報告（透過支援發送 TLS 報告的服務）。 範例條目（對於 example.com 網域）： 
    smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»

    此條目指示郵件寄件者將 SMTP 中 TLS 使用情況的統計報告傳送至 [email protected].

    監視報告幾天以確保沒有錯誤。

  4. 透過 HTTPS 發布 MTA-STS 策略。 該策略以文字檔案形式發布，其中按位置包含 CRLF 行終止符。 
    https://mta-sts.example.com/.well-known/mta-sts.txt

    政策範例：

    version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400

    版本欄位包含策略的版本（目前 STSv1），Mode設定策略應用模式，testing－測試模式（策略不應用），enforce－「戰鬥」模式。 先以mode:testing方式發佈策略，如果測試模式下策略沒有問題，過一段時間就可以切換到mode:enforce。

    在 mx 中，指定了可以接受您的網域的郵件的所有郵件伺服器的清單（每個伺服器必須配置與 mx 中指定的名稱相符的憑證）。 Max_age 指定政策的快取時間（一旦記住的策略將被套用，即使攻擊者在快取時間內阻止其傳遞或損壞 DNS 記錄，您也可以透過變更 mta-sts DNS 來發出需要再次要求政策的訊號記錄） 。

  5. 在 DNS 中發布 TXT 記錄：  
    _mta-sts.example.com. TXT “v=STS1; id=someid;”

    id 欄位中可以使用任意識別碼（例如時間戳）；當策略更改時，它應該更改，這允許發送者了解他們需要重新請求快取的策略（如果標識符與快取的策略不同）快取一個）。

發送方的 MTA-STS 支持

到目前為止，她的處境很糟糕，因為… 新鮮的標準。

作為「強制 TLS」的後記

最近，監管機構一直在關注電子郵件安全（這是一件好事）。 例如，DMARC 對美國所有政府機構都是強制性的，在金融領域的需求也越來越大，該標準在監管領域的滲透率達到 90%。 現在，一些監管機構要求對各個域實施“強制 TLS”，但確保“強制 TLS”的機制並沒有定義，而且在實踐中，這種設置的實施方式往往無法最低限度地防範已經發生的真實攻擊。在DANE 或MTA-STS 等機制中提供。

如果監管機構要求在單獨的領域中實施“強制 TLS”，我們建議考慮 MTA-STS 或其部分類似機製作為最合適的機制，它無需為每個域單獨進行安全性設定。 如果您在實現 MTA-STS 的客戶端部分時遇到困難（在協議獲得廣泛支援之前，他們很可能會這樣做），我們可以推薦這種方法：

  1. 發布 MTA-STS 政策和/或 DANE 記錄（僅當已為您的網域啟用 DNSSEC 且在任何情況下啟用 MTA-STS 時，DANE 才有意義），這將保護您方向的流量並無需詢問其他郵件服務如果郵件服務已支援MTA-STS 和/或DANE，請為您的網域設定強制TLS。
  2. 對於大型電子郵件服務，透過每個網域的單獨傳輸設定實現 MTA-STS 的“模擬”，這將修復用於郵件中繼的 MX，並需要對其進行 TLS 憑證的強制驗證。 如果網域已經發布了 MTA-STS 策略，則這可能可以輕鬆完成。 從安全角度來看，在不修復中繼並驗證其憑證的情況下為網域啟用強制 TLS 本身是無效的，並且不會為現有的 STARTTLS 機制添加任何內容。

來源： www.habr.com

添加評論