STARTTLS，是一种明文通信协议的扩展，能够让明文的通信连线直接成为加密连线(使用SSL或TLS加密)，而不需要使用另一个特别的端口来进行加密通信，属于机会性加密。

电子邮件客户端和服务器之间的连接提供了两种使用 TLS 保护的方法：隐性 TLS 从一开始就对连接进行加密并在单独的端口上运行，而 STARTTLS 提供了一种将现有未加密连接升级到 TLS 的机制。

有时 STARTTLS 被视为一种机会加密模式，仅在可用时提供 TLS 保护。这很容易受到降级攻击。但是，现代电子邮件客户端通常期望强制执行 STARTTLS，并且在启用时，不可能进行未加密的通信。

通过STARTTLS升级连接是很脆弱的，容易受到许多安全漏洞和攻击的影响。我们在 STARTTLS 实现中发现了 40 多个漏洞。我们的结论是，这些漏洞是如此普遍，所以我们建议尽可能避免使用STARTTLS。

我们假设中间人 (MitM) 攻击者可以修改电子邮件客户端和提供商的电子邮件服务器之间建立的连接。

通过命令注入使用 SMTP 和 IMAP 窃取登录凭据

2011 年，Postfix 开发人员 Wietse Venema 描述了 STARTTLS 实现中的一个漏洞，该漏洞允许注入服务器将其解释为加密连接的一部分的明文命令。这是通过使用 STARTTLS 命令向同一 TCP 段中的服务器发送附加命令来实现的。

我们发现，尽管自2011年以来人们就知道这个漏洞，但它仍然非常普遍。截止目前共发现了15个易受攻击的实现场景，在扫描中，2%的邮件服务器显示了这个漏洞。

此命令注入可用于通过 SMTP 和 IMAP 协议窃取凭据。

我们的攻击需要一个中间人 (MitM) 攻击者，该攻击者可以修改网络流量并在同一服务器上拥有自己帐户的登录凭据。攻击者可以注入对其进行身份验证的命令，然后开始发送 (SMTP) 或存储 (IMAP) 电子邮件，受害者发送的登录凭据将存储在攻击者可以访问的电子邮件中。

命令注入还可用于跨协议攻击，以使用邮件服务器的证书提供 HTTPS 内容。

通过响应注入伪造邮箱内容

我们发现了一种类似于电子邮件客户端应用程序中的命令注入的攻击，称之为响应注入。此漏洞影响了许多流行的邮件客户端，包括 Apple Mail、Mozilla Thunderbird、Claws Mail 和 Mutt。

通过在 TLS 握手之前向服务器消息注入额外的内容以响应 STARTTLS 命令，我们可以注入服务器命令，客户端将处理这些命令，就好像它们是加密连接的一部分一样，这可用于伪造邮箱内容。

通过 PREAUTH 和 REFERRAL 窃取凭据的 IMAP 连接降级

在 IMAP 协议中，服务器可以通过 PREAUTH 命令在第一条消息中通知客户端它已经通过了身份验证。该协议禁止在已验证状态下使用 STARTTLS 命令。因此，如果客户端应用程序接受 PREAUTH，则它无法强制执行 STARTTLS。

中间人攻击者可以使用它来阻止 STARTTLS 升级连接并强制客户端使用未加密的连接。该漏洞最初于2014年在Trojitá中被发现。我们发现，其他多个电子邮件客户端应用程序也容易受到同一漏洞的攻击。

此漏洞与 IMAP 功能登录引用和邮箱引用结合使用时尤其严重，这些命令允许服务器指示客户端登录到另一个 IMAP 服务器。通过使用 PREAUTH 来防止加密连接，攻击者可以使用引用来强制客户端将凭据发送到攻击者控制的服务器。幸运的是，许多客户端不支持推荐功能。我们发现只有一个客户—— Alpine，容易受到这种 PREAUTH 和推荐组合的影响。

总结

本文描述的所有漏洞都依赖于不安全连接到安全连接的转换，隐性 TLS 没有这样的转换，因此不容易受到这些攻击。因此，我们认为隐性 TLS 比 STARTTLS 更安全。

我们还指出 STARTTLS 总是引入至少一个额外的连接，所以隐性 TLS 通常提供更好的性能。

安全影响

我们认为本文所讲的攻击难以大规模执行，主要用于有针对性的攻击。因此，你应该始终更新软件并重新配置电子邮件客户端以只使用隐性 TLS。

安全建议

对于电子邮件客户端用户

如果可能，我们建议用户检查并配置他们的电子邮件客户端，以在专用端口上使用带有隐性 TLS 的 SMTP、POP3 和 IMAP，即SMTP/Submission端口465，POP3端口995，IMAP端口993。某些邮件服务提供商，尤其是 Microsoft 和 Apple，不支持SMTP/Submission的隐式TLS。我们建议用户让他们的邮件服务提供商提供更安全的隐性 TLS 选项。

对于应用程序开发人员

默认情况下，电子邮件服务器和客户端应用程序都应提供隐性 TLS。从长远来看，软件开发人员可能会决定根本不支持 STARTTLS，从而简化他们的代码和配置对话框和文件。

我们建议在服务器端和客户端审核所有支持 STARTTLS 的应用程序，因为应用程序需要确保没有未加密的内容作为加密连接的一部分被处理。 IMAP 应用程序必须确保它们不允许将 PREAUTH 与 STARTTLS 结合使用，可以使用EAST 工具包，它允许测试应用程序。

对于邮件服务器管理员

确保你使用的服务器支持所有支持的协议的隐性 TLS，如果可能，请考虑为 IMAP、POP3 和 SMTP 提交禁用 STARTTLS。

如果你确实需要支持 STARTTLS，建议使用建议的工具针对所有支持的协议的命令注入漏洞测试服务器。如果服务器软件易受攻击，立马应该进行安全更新。

常见问题

STARTTLS不安全吗?

STARTTLS有两种“模式”，“机会主义模式”和“强制模式”。电子邮件客户端在提交新邮件或访问现有邮件之前必须使用用户名和密码进行身份验证。对于这些连接，必须严格执行通过STARTTLS传输到TLS的转换，因为降级将暴露用户名和密码，并给予攻击者对电子邮件帐户的完全访问权。

如何测试使用的软件是否易受攻击?

我们了提供允许测试电子邮件客户端和服务器的 EAST 工具包。

使用我们的命令注入测试器测试电子邮件服务器的命令注入相对容易。 testssl.sh(开发版)和 TLS-Attacker/TLS-Scanner也会检查命令注入。

其他支持 STARTTLS 或类似机制的协议是否受到影响?

我们希望在其他使用 STARTTLS 的协议中看到类似的漏洞，例如 XMPP、FTP、IRC 或 LDAP。因此，我们建议避免 STARTTLS 并尽可能使用隐性 TLS。

邮件服务器之间的通信(MTA到MTA)如何处理?

传统上，电子邮件服务器之间的 STARTTLS 只能防止被动攻击，容易受到主动攻击，例如 STARTTLS 攻击。