STARTTLS，是一種明文通信協(xié)議的擴展，能夠讓明文的通信連線直接成為加密連線（使用SSL或TLS加密），而不需要使用另一個特別的端口來進行加密通信，屬于機會性加密。
電子郵件客戶端和服務器之間的連接提供了兩種使用 TLS 保護的方法：隱性 TLS 從一開始就對連接進行加密并在單獨的端口上運行，而 STARTTLS 提供了一種將現(xiàn)有未加密連接升級到 TLS 的機制。
有時 STARTTLS 被視為一種機會加密模式，僅在可用時提供 TLS 保護。這很容易受到降級攻擊。但是，現(xiàn)代電子郵件客戶端通常期望強制執(zhí)行 STARTTLS，并且在啟用時，不可能進行未加密的通信。
通過STARTTLS升級連接是很脆弱的，容易受到許多安全漏洞和攻擊的影響。我們在 STARTTLS 實現(xiàn)中發(fā)現(xiàn)了 40 多個漏洞。我們的結論是，這些漏洞是如此普遍，所以我們建議盡可能避免使用STARTTLS。
我們假設中間人 （MitM） 攻擊者可以修改電子郵件客戶端和提供商的電子郵件服務器之間建立的連接。
通過命令注入使用 SMTP 和 IMAP 竊取登錄憑據(jù)
2011 年，Postfix 開發(fā)人員 Wietse Venema 描述了 STARTTLS 實現(xiàn)中的一個漏洞，該漏洞允許注入服務器將其解釋為加密連接的一部分的明文命令。這是通過使用 STARTTLS 命令向同一 TCP 段中的服務器發(fā)送附加命令來實現(xiàn)的。
我們發(fā)現(xiàn)，盡管自2011年以來人們就知道這個漏洞，但它仍然非常普遍。截止目前共發(fā)現(xiàn)了15個易受攻擊的實現(xiàn)場景，在掃描中，2%的郵件服務器顯示了這個漏洞。
此命令注入可用于通過 SMTP 和 IMAP 協(xié)議竊取憑據(jù)。
我們的攻擊需要一個中間人 （MitM） 攻擊者，該攻擊者可以修改網(wǎng)絡流量并在同一服務器上擁有自己帳戶的登錄憑據(jù)。攻擊者可以注入對其進行身份驗證的命令，然后開始發(fā)送 （SMTP） 或存儲 （IMAP） 電子郵件，受害者發(fā)送的登錄憑據(jù)將存儲在攻擊者可以訪問的電子郵件中。
命令注入還可用于跨協(xié)議攻擊，以使用郵件服務器的證書提供 HTTPS 內(nèi)容。
通過響應注入偽造郵箱內(nèi)容
我們發(fā)現(xiàn)了一種類似于電子郵件客戶端應用程序中的命令注入的攻擊，稱之為響應注入。此漏洞影響了許多流行的郵件客戶端，包括 Apple Mail、Mozilla Thunderbird、Claws Mail 和 Mutt。
通過在 TLS 握手之前向服務器消息注入額外的內(nèi)容以響應 STARTTLS 命令，我們可以注入服務器命令，客戶端將處理這些命令，就好像它們是加密連接的一部分一樣，這可用于偽造郵箱內(nèi)容。
通過 PREAUTH 和 REFERRAL 竊取憑據(jù)的 IMAP 連接降級
在 IMAP 協(xié)議中，服務器可以通過 PREAUTH 命令在第一條消息中通知客戶端它已經(jīng)通過了身份驗證。該協(xié)議禁止在已驗證狀態(tài)下使用 STARTTLS 命令。因此，如果客戶端應用程序接受 PREAUTH，則它無法強制執(zhí)行 STARTTLS。
中間人攻擊者可以使用它來阻止 STARTTLS 升級連接并強制客戶端使用未加密的連接。該漏洞最初于2014年在Trojitá中被發(fā)現(xiàn)。我們發(fā)現(xiàn)，其他多個電子郵件客戶端應用程序也容易受到同一漏洞的攻擊。
此漏洞與 IMAP 功能登錄引用和郵箱引用結合使用時尤其嚴重，這些命令允許服務器指示客戶端登錄到另一個 IMAP 服務器。通過使用 PREAUTH 來防止加密連接，攻擊者可以使用引用來強制客戶端將憑據(jù)發(fā)送到攻擊者控制的服務器。幸運的是，許多客戶端不支持推薦功能。我們發(fā)現(xiàn)只有一個客戶—— Alpine，容易受到這種 PREAUTH 和推薦組合的影響。
總結
本文描述的所有漏洞都依賴于不安全連接到安全連接的轉(zhuǎn)換，隱性 TLS 沒有這樣的轉(zhuǎn)換，因此不容易受到這些攻擊。因此，我們認為隱性 TLS 比 STARTTLS 更安全。
我們還指出 STARTTLS 總是引入至少一個額外的連接，所以隱性 TLS 通常提供更好的性能。
安全影響
我們認為本文所講的攻擊難以大規(guī)模執(zhí)行，主要用于有針對性的攻擊。因此，你應該始終更新軟件并重新配置電子郵件客戶端以只使用隱性 TLS。
安全建議
?對于電子郵件客戶端用戶
如果可能，我們建議用戶檢查并配置他們的電子郵件客戶端，以在專用端口上使用帶有隱性 TLS 的 SMTP、POP3 和 IMAP，即SMTP/Submission端口465，POP3端口995，IMAP端口993。某些郵件服務提供商，尤其是 Microsoft 和 Apple，不支持SMTP/Submission的隱式TLS。我們建議用戶讓他們的郵件服務提供商提供更安全的隱性 TLS 選項。
?對于應用程序開發(fā)人員
默認情況下，電子郵件服務器和客戶端應用程序都應提供隱性 TLS。從長遠來看，軟件開發(fā)人員可能會決定根本不支持 STARTTLS，從而簡化他們的代碼和配置對話框和文件。
我們建議在服務器端和客戶端審核所有支持 STARTTLS 的應用程序，因為應用程序需要確保沒有未加密的內(nèi)容作為加密連接的一部分被處理。IMAP 應用程序必須確保它們不允許將 PREAUTH 與 STARTTLS 結合使用，可以使用EAST 工具包，它允許測試應用程序。
?對于郵件服務器管理員
確保你使用的服務器支持所有支持的協(xié)議的隱性 TLS，如果可能，請考慮為 IMAP、POP3 和 SMTP 提交禁用 STARTTLS。
如果你確實需要支持 STARTTLS，建議使用建議的工具針對所有支持的協(xié)議的命令注入漏洞測試服務器。如果服務器軟件易受攻擊，立馬應該進行安全更新。
常見問題
?STARTTLS不安全嗎？
STARTTLS有兩種“模式”，“機會主義模式”和“強制模式”。電子郵件客戶端在提交新郵件或訪問現(xiàn)有郵件之前必須使用用戶名和密碼進行身份驗證。對于這些連接，必須嚴格執(zhí)行通過STARTTLS傳輸?shù)絋LS的轉(zhuǎn)換，因為降級將暴露用戶名和密碼，并給予攻擊者對電子郵件帳戶的完全訪問權。
?如何測試使用的軟件是否易受攻擊？
我們了提供允許測試電子郵件客戶端和服務器的 EAST 工具包。
使用我們的命令注入測試器測試電子郵件服務器的命令注入相對容易。testssl.sh（開發(fā)版）和 TLS-Attacker/TLS-Scanner也會檢查命令注入。
?其他支持 STARTTLS 或類似機制的協(xié)議是否受到影響？
我們希望在其他使用 STARTTLS 的協(xié)議中看到類似的漏洞，例如 XMPP、FTP、IRC 或 LDAP。因此，我們建議避免 STARTTLS 并盡可能使用隱性 TLS。
?郵件服務器之間的通信（MTA到MTA）如何處理？
傳統(tǒng)上，電子郵件服務器之間的 STARTTLS 只能防止被動攻擊，容易受到主動攻擊，例如 STARTTLS 攻擊。
