STARTTLS是否比TLS / SSL安全吗？

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

据我了解，“ STARTTLS”的简单含义是“如果两端都支持TLS，则加密，否则不加密传输”。“ SSL / TLS”简单地表示“总是加密或根本不连接”。这个对吗？

换句话说：

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

基于SMTP的STARTTLS RFC（RFC 3207），答案是：

STARTTLS不如TLS安全。

除了让我自己说话之外，我将允许RFC自己说，用粗体突出显示四个相关的位：

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

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

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

两种选择之间的安全性没有区别。

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

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

通常，仅在最终客户端和服务器之间使用SSL / TLS。在MTA之间更常用STARTTLS来保护服务器间的传输。

给定这两种实现方式，如果用户或管理员假定连接已加密但实际上未将其配置为需要加密，则STARTTLS可以解释为不安全。但是，所使用的加密与SSL / TLS完全相同，因此除了这种类型的配置错误外，它或多或少都不会受到中间人攻击。

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

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

• TLS版本1.2或更高版本可用于MUA与邮件提交服务器之间以及MUA与邮件访问服务器之间的所有通信。
• MUA和邮件服务提供商（a）不鼓励将明文协议用于邮件访问和邮件提交，并且（b）在可行的情况下尽快弃用明文协议。
• 使用“隐式TLS”（定义如下）建立到邮件提交服务器和邮件访问服务器的 连接，而不是连接到“明文”端口并使用STARTTLS命令或类似命令来协商TLS。

（添加了重点）

答案在某种程度上取决于您所指的“安全”。

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

• 借助SSL / TLS，客户端将打开一个与“ SSL端口”的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和“先尝试一个端口然后再尝试另一个端口”是很简单的，以使您的客户端恢复为纯文本格式。是的，这确实发生了，这只是网络如何监视您的流量的一个示例。而且此类攻击不仅限于由三个字母组成的国家支持的机构，

是的，您拥有基本权利。是的，STARTTLS绝对不太安全。它不仅可以在不通知的情况下故障恢复为纯文本，还因为它受到中间人攻击。由于连接是明文开始的，因此MitM可以剥离STARTTLS命令，并防止加密发生。但是，我相信邮件服务器可以指定仅在设置加密隧道之后才进行传输。因此，您可以解决此问题。

那么，为什么这样的事情甚至存在呢？出于兼容性原因。如果任何一方都不支持加密，则您可能仍希望连接正确完成。

同意@Greg。这些攻击是可能的。但是，可以将MTA配置为（取决于MTA）使用“强制性TLS”，而不是“机会性TLS”。这意味着电子邮件交易使用TLS且仅使用TLS（这也包括STARTTLS）。如果远程MTA不支持STARTTLS，则电子邮件将被退回。

不，这是不是不太安全，当你的应用程序处理它正确。

有四种处理TLS的方法，许多程序允许您选择：

• 没有TLS
• 专用端口上的TLS（仅尝试TLS）
• 使用TLS（如果可用）（尝试starttls，失败时使用未加密的连接）
• 始终使用TLS（starttls如果无法使用，则使用并失败）

专用端口上的TLS的优点是，可以确保在使用尚不知道的程序时，或者没有在其首次启动向导中未公开用于错误处理的详细设置的情况下，没有回退。

但是总的来说，安全性取决于对安全性错误的处理。当TLS端口上的TLS也失败时，程序可能会决定切换到纯文本端口。您需要知道它将执行的操作并选择安全设置。并且程序应使用安全的默认值。