STARTTLS 不如 TLS/SSL 安全吗？

Question

在 Thunderbird（我也假设在许多其他客户端中）中，我可以选择在“SSL/TLS”和“STARTTLS”之间进行选择。

据我了解，“STARTTLS”简单来说就是“如果两端都支持 TLS 则加密，否则不加密传输”。而“SSL/TLS”简单来说就是“始终加密或根本不连接”。这样对吗？

或者换句话说：

STARTTLS 是否不如 SSL/TLS 安全，因为它可以在不通知我的情况下回退到纯文本？

Answer 1

基于 SMTP 的 STARTTLS RFC ( RFC 3207 )的答案是：

STARTTLS 不如 TLS 安全。

我不会自己说话，而是让 RFC 自己说话，用粗体突出显示四个相关位：

可以通过从服务器删除“250 STARTTLS”响应来发起中间人攻击。这将导致客户端不会尝试启动 TLS 会话。另一种中间人攻击是允许服务器宣布其 STARTTLS 功能，但更改客户端启动 TLS 的请求和服务器的响应。为了防御此类攻击，客户端和服务器都必须能够配置为在消息可以成功传输之前，要求对选定主机的适当密码套件进行成功的 TLS 协商。还应该提供在可能的情况下使用 TLS的附加选项。一个实施可能 提供记录在与给定对等方通信时使用的 TLS 的能力，并在以后的会话中未使用时生成警告。

如果 TLS 协商失败或客户端收到 454 响应，则客户端必须决定下一步要做什么。 有三个主要选择：继续 SMTP 会话的其余部分，[...]

如您所见，RFC 本身声明（不是很清楚，但足够清楚）没有任何要求客户端建立安全连接并在安全连接失败时通知用户。它明确地为客户端提供了静默建立纯文本连接的选项。

Answer 2

这两个选项之间的安全性没有区别。

• SSL/TLS 首先打开 SSL/TLS 连接，然后开始 SMTP 事务。这必须发生在尚未运行非 SSL/TLS SMTP 服务器的端口上；由于协议的性质，不可能配置单个端口来处理纯文本和加密连接。

• STARTTLS 启动 SMTP 事务并在对 EHLO 的响应中寻找另一端对 TLS 的支持。如果客户端在支持的命令列表中看到 STARTTLS，则它会发送 STARTTLS 并开始协商加密。所有这些都可以（并且通常确实）发生在 25 的标准 SMTP 端口上，部分原因是为了向后兼容，但也允许在既支持它但不一定需要它的端点之间进行机会加密。

通常，SSL/TLS 仅用于终端客户端和服务器之间。STARTTLS 更常用于 MTA 之间以保护服务器间传输。

鉴于这两个实现，如果用户或管理员假设连接已加密但实际上并未将其配置为需要加密，则 STARTTLS 可能被解释为不安全。但是，所使用的加密与 SSL/TLS 完全相同，因此除了这种类型的配置错误之外，不会或多或少地容易受到中间人攻击。

Answer 3

特别是对于电子邮件，2018 年 1 月发布了RFC 8314，它明确建议在 IMAP、POP3 和 SMTP 提交时优先使用“隐式 TLS”而不是 STARTTLS 机制。

简而言之，本备忘录现在建议：

• TLS 1.2 或更高版本用于 MUA 和邮件提交服务器之间以及 MUA 和邮件访问服务器之间的所有流量。
• MUA 和邮件服务提供商 (MSP) (a) 不鼓励使用明文协议进行邮件访问和邮件提交，并且 (b) 尽快弃用明文协议用于这些目的。
• 使用“隐式 TLS”（定义如下）连接到邮件提交服务器和邮件访问服务器，优先 连接到“明文”端口并使用 STARTTLS 命令或类似命令协商 TLS。

（强调）

Answer 4

答案在某种程度上取决于您所说的“安全”是什么意思。

首先，您的摘要并没有完全体现 SSL/TLS 和 STARTTLS 之间的区别。

• 使用 SSL/TLS，客户端打开一个 TCP 连接到分配给它想要使用的应用程序协议的“SSL 端口”，并立即开始使用 TLS。
• 使用 STARTTLS，客户端打开一个到“明文端口”的 TCP 连接，该连接与它想要使用的应用程序协议相关联，然后询问服务器“你支持哪些协议扩展？”。然后服务器以扩展列表作为响应。如果这些扩展名之一是“STARTTLS”，那么客户端可以说“好吧，让我们使用 TLS”，然后两人开始说 TLS。

如果客户端配置为需要 TLS，则这两种方法或多或少同样安全。但是对于必须如何使用 STARTTLS 来确保其安全有一些微妙之处，而且 STARTTLS 实现要正确地获取这些细节有点困难。

另一方面，如果客户端配置为仅在 TLS 可用时使用 TLS，而在 TLS 不可用时使用明文，则客户端可能会首先尝试连接到协议使用的 SSL 端口，如果失败，然后连接到明文端口并尝试使用 STARTTLS，如果 TLS 在任何一种情况下都不可用，最后回退到明文。攻击者很容易导致 SSL 端口连接失败（只需要一些适时的 TCP RST 数据包或阻止 SSL 端口）。对于攻击者来说，击败 STARTTLS 协商并导致流量保持明文状态有点困难 - 但只是一点点。然后攻击者不仅可以阅读您的电子邮件，还可以捕获您的用户名/密码以备将来使用。

因此，简单的答案是，如果您要连接到已知支持 TLS 的服务器（发送或阅读电子邮件时应该如此），则应使用 SSL/TLS。如果连接受到攻击，连接尝试将失败，但您的密码和电子邮件不会被泄露。

另一方面，如果您连接到某些您不知道它是否支持 TLS 的服务，则 STARTTLS 可能会稍微好一些。

发明 STARTTLS 时，“被动”仅侦听攻击非常普遍，攻击者注入流量以尝试降低安全性的“主动”攻击不太常见。从那时起的 20 年左右，主动攻击变得更加可行和普遍。

例如，如果您尝试在机场或其他公共场所使用笔记本电脑并尝试通过那里提供的 wifi 阅读邮件，则您不知道该 wifi 网络对您的流量做了什么。wifi 网络将某些类型的流量路由到“代理”是很常见的，这些“代理”介于您的客户端应用程序和它们试图与之通信的服务器之间。这些代理禁用 STARTTLS 和“尝试一个端口然后另一个端口”以试图让您的客户端回退到明文是微不足道的。是的，这种情况会发生，这只是网络如何监视您的流量的一个示例。此类攻击不仅限于国家支持的三个字母的机构，