LWN: STARTTLS 的坏处！

关注了就能看到更多这么棒的文章哦～

STARTTLS considered harmful

By Jake Edge
August 18, 2021
DeepL assisted translation
https://lwn.net/Articles/866481/

Transport Layer Security（TLS）加密方式在如今的互联网上已经是无处不在了，尽管绝大多数部署应用都是发生在过去的近 20 年期间。它的前身，Secure Socket Layer（SSL）的第一个公开版本出现在 1995 年。在那之前，互联网通讯协议一般不进行加密，从而为各种类型的 "中间人"（MitM，meddler-in-the-middle）攻击提供了肥沃的土壤。后来，一些些一种添加了 STARTTLS 命令，成为了一种增加 TLS 支持并且可以向后兼容的方式，但多年来该机制一直存在着一些缺陷和漏洞。最近的一些研究（名为 "NO STARTTLS "）就介绍了更多的类似漏洞，并得出结论认为现在可能就是应该完全放弃使用 STARTTLS 的时候了。

Opportunistic TLS

通常，协议消息（protocol messages）要么加密，要么不加密，但 STARTTLS 允许了一种中间状态。这个命令可以在一个当前是明文的连接中使用 TLS 功能，这也就是人们所谓的 opportunistic TLS。服务器可以公告自己能处理的 TLS 连接的能力。例如，电子邮件（SMTP/ESMTP）服务器在回复客户发出的第一条信息（EHLO）时，可以告知客户自己是否接受 STARTTLS 命令。客户端如果有需要的话就可以使用 STARTTLS 命令来请求加密了。接下来将进行 TLS 握手，后续的通信就是被加密进行的了。implicit TLS 则与之不同，这里的通信通道（communication channel）通常是在一个专用的端口号上进行的，完全是在加密模式。

可以预料到，从一种模式切换到另一种模式的时候是最容易受到 MitM 攻击的。最基本的攻击被称为 STARTTLS stripping，只要攻击者能够拦截和改变网络数据，那么他就可以很容易地阻止参与者之间发送的 STARTTLS 命令，从而使得双方的交流一直以明文形式进行。客户端在建立加密会话的时候如果失败了，它有可能会将此视为一个错误，但有时却可能不是这么判断的。尝试建立加密连接之后的下一步动作往往是进行一些身份认证，如果 session 没有加密的话，可能实际上就变成以明文形式进行身份认证了。

正如研究人员之一 Hanno Böck 在 oss-security 邮件列表中所报告的，2011 年发现了一个 STARTTLS 缺陷可以作为研究的出发起点。这个缺陷是由 Postfix 的创建者 Wietse Venema 在包括 Postfix 在内的多个 SMTP 服务器中发现的，它使得 MitM 攻击者可以 "在 STARTTLS 命令的 TCP 包中注入明文内容，而服务端程序会将其解释为 TLS session 的一部分"，Böck 如此陈述道。但研究人员发现这个已有十年历史的漏洞在一些服务器中仍未得到 fix。在其最坏情况下，"它可以被用来窃取凭证（credential）信息"。

其他研究人员比如 Damian Poddebniak、Fabian Ising 和 Sebastian Schinzel 来自明斯特应用科技大学，而 Böck 是一名独立研究人员。他们在 8 月份的第 30 届 USENIX 安全研讨会上发表了他们的论文。作为这项工作的一部分，他们开发了一个名为 EAST 的 testing toolkit，用来分析了 28 个电子邮件客户端程序和 23 个服务端程序。只有三个客户端和七个服务端软件可以完全不受他们所发现的 40 个不同 STARTTLS 问题的影响。此外，事实证明，有 15 种服务端程序仍然容易受到 Venema 在 2011 年发现的同一缺陷的影响。扫描之后发现，互联网上 2%的邮件服务器都具有该漏洞。论文和网站上都有关于所有这些漏洞的更多细节，包括哪些服务端和客户端程序会受影响。

研究人员还研究了 POP3 和 IMAP 信息检索协议（message-retrieval protocols），这两个协议都有 STARTTLS 命令。就像 Venema 在 SMTP 中看到的一样，他们也发现一些服务端程序会将与命令一起发送的明文正常处理，就好像它是加密会话的一部分一样。在 TLS 握手结束后，服务器并没有丢弃任何缓冲中输入信息，而是在 TLS 握手结束后继续对其进行处理，而这时连接的状态已经改变过了。

最严重的攻击是利用这种行为来窃取用户的登录凭证。不过，它们要求攻击者在相关的 SMTP 或 IMAP 服务器上也有一个有效账户，这在一定程度上缩小了影响范围：

攻击者可以注入命令从而让他们自己得以通过认证，然后开始发送（利用 SMTP）或存储（利用 IMAP）一封电子邮件。受攻击者发出的登录凭证信息会被存储在攻击者可以访问到的这封电子邮件中。

从另一个角度看的话，邮箱内容也完全可以通过向服务端的 STARTTLS 响应信息中添加命令来伪造出来。这里也需要数据被缓冲起来，接下来在加密会话的上下文中进行解释，不过这次是在电子邮件客户端程序这边发生的了，尽管这个命令是在建立会话之前就发送（和接收）到的：

这个 bug 对许多流行的邮件客户端都有影响，包括 Apple Mail、Mozilla Thunderbird、Claws Mail 和 Mutt。

通过在 TLS 握手前服务端程序对 STARTTLS 命令回复时的信息中注入额外的内容，就可以让客户端将其当作为加密连接中的数据来处理。这可以用来伪造邮箱内容。

在关于 NO STARTTLS 这些漏洞的网页上，研究人员公布了他们发现的第三类漏洞。在 IMAP 连接中，服务器端可能会发送 PREAUTH 命令来表明客户端已经通过了认证，但它也导致客户端不可以再使用 STARTTLS 过渡到加密状态。IMAP 协议不允许在 PREAUTH 之后使用 STARTTLS，这就使得 PREAUTH 成为了一种阻止加密通讯的方式，有点类似于 STARTTLS stripping 漏洞。当用户要求进行加密传输时，客户端应该拒绝进行这种类型的连接，但有些程序并没有这样做。这个漏洞是 2014 年在 Trojitá 电子邮件客户端中发现的，但研究人员发现其他客户端也容易受到影响。

再配合上人们很少使用的 IMAP referral 功能（for logins 和 for mailboxes），攻击者可以让客户端直接把自己的证书发送给攻击者：

通过使用 PREAUTH 来阻止加密连接，攻击者可以使用 referral 功能来迫使客户端将凭证信息发送到攻击者所控制的服务器上去。幸运的是，许多客户端程序都不支持 referral 功能。我们只发现有一个客户端（Alpine）容易受到这种 PREAUTH 和 referral 组合攻击的影响。

Recommendations

研究人员建议用户坚持使用 implicit TLS 端口（包括用于 SMTP 提交的 465 端口，用于 IMAP 的 993 端口，用于 POP3 的 995 端口），从而完全避免使用 STARTTLS。不过一些服务提供商并没有在电子邮件服务中提供相应的支持。应用程序开发人员应尽量只考虑提供对 implicit TLS 的支持。如果这不可行的话，就需要用 EAST 或类似的东西来进行测试，确保明文不会被当作加密数据处理。同时，邮件服务器管理员应该考虑在电子邮件处理协议中禁用 STARTTLS。

正如文章的 FAQ 部分所指出的，STARTTLS 是邮件服务器（邮件传输代理，MTA，mail transfer agents）对它们之间进行的数据交互进行加密的唯一方法，因为当 SMTP 被用来在 MTA 之间传输邮件时，并不支持 implicit TLS。那些 STARTTLS 传输很容易受到 STARTTLS stripping 的攻击，因为服务器并不知道另一端是否接受 TLS。他们不能因为连接没有加密就拒绝传输邮件。这意味着攻击者并没有什么动力去采用 NO STARTTLS 中提到的这些漏洞。然而，在服务器之间相互的连接中加入认证的工作正在进行中，这将改变现状，所以也需要分析一下服务器端代码的 buffer 机制以及其他类型的 STARTTLS 问题了。

MitM 漏洞只有在能够改变两端之间信息的情况下才能被利用来进行攻击，因此有时被视为破坏性不那么大的漏洞。它们确实是受限于这个限制条件。但有时候人们错误地估计了这个中间人攻击者所需要达成条件的困难程度。任何一个 WiFi 路由器，比如在本地的咖啡馆、或互联网服务提供商提供的路由器，都必定有能力进行这些类型的攻击，这完全不需要国家层面的力量来攻击互联网骨干网。WiFi 路由器，特别是那些在繁忙地点支持大量用户的路由器，将会成为攻击者希望完全掌控的主要目标。只要拿到了掌控权，那么针对其所有用户的各种 MitM 攻击都拥有了一个完美的平台。

虽然 NO STARTTLS 漏洞都很重要，应该被修复，但它们本身一般不是大问题。正如研究人员所指出的，它们的影响相当有限：

我们所演示的攻击都需要有人在进行主动攻击，而在使用一个可以强制保证转换到 TLS 的电子邮件客户端时完全可以识别出这些攻击。我们已经通知了所有的流行电子邮件客户端和服务端的开发商，大多数问题已经被修复。我们认为，这里所演示的攻击很难得以大规模执行，我们预期它们主要会被用于进行有针对性的攻击。

这些漏洞确实突出强调了一点，那就是并不是所有项目都在仔细检查他们的代码从而找出其他类似工具中已经发生过的同类问题。几年前发现的漏洞完全应该使得其他电子邮件服务端和客户端软件项目在很久以前就在自己的代码中找出这些类似漏洞了。可是事实正相反，还是一些安全研究人员继续对 STARTTLS 这个痛点继续分析才找出的问题。

很明显，在现有的协议中加固得更加安全是很困难的。在同一个连接上混合着来使用明文和加密的数据传输而希望不出现这类故障，显然也是很困难的。在我们前进的过程中，这些通常原则都是非常重要的。向后兼容当然大多数情况下都是个 "nice to have" 的选择，但没有缺陷以及很难处理场景的安全协议正日益成为 "must have" 的东西。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～