如何缓解电子邮件服务器之间的 STARTTLS MITM（降级和伪造证书）？

Question

我不像本网站上的大多数人那样在技术上倾向于，所以请记住这一点。我想了解更多关于电子邮件安全的知识，所以我做了一些研究，一切都根据我的理解，所以请在需要的地方纠正我。客户端和服务器（MSA/MTA？）之间的连接可以加密，但服务器到服务器（MTA 到 MTA？）之间的加密取决于每个支持 STARTTLS 的服务器。STARTTLS 也可以在客户端和服务器之间实现。

我遇到的 STARTTLS 的唯一弱点是连接可以通过加密或纯文本形式被接受，因此它使 MITM 攻击变得微不足道，其中加密可以降级为纯文本。我也知道伪造证书存在问题，尽管我不知道这是否与 MITM 直接相关。

我读到这是一个实施问题，而不是协议本身。我遇到的一些解决方案涉及将客户端配置为在未通过 SSL/TLS 发生连接时发出通知或完全断开连接。是否有一种正确的方法来实现 STARTTLS 以便 MITM 是不可能的（而不是在它发生时对其做出反应，如果有意义的话）以及会在哪里发生？这些修复程序是打算覆盖服务器到服务器的连接还是只是客户端到服务器的连接？我还想更多地了解假证书的问题，这种弱点是如何可能的，以及如何通过实施或其他方式解决它。

我最感兴趣的是服务器到服务器之间的安全性，因为服务器到客户端似乎不是一个问题，并且已经被大多数 ESP 解决了。有没有更好的 STARTTLS 替代方案？正如我所提到的，我对这一切都不熟悉，我需要对其中大部分内容进行全面指导，包括如何实施/配置。如果没有人能在这里提供，就学习资源而言，我会很感激任何正确方向的观点。

另一方面......我也有兴趣了解实际的攻击/利用，我想知道上面提到的 MITM（服务器到服务器）类型是否可以针对特定连接（目标电子邮件地址？）或者更类似于抓住路过的任何东西。

Answer 1

以安全方式传输电子邮件存在几个问题，最好在 security.stackexchange.com 上询问这些问题。邮件可以在不同阶段被拦截：

• 显式 TLS (STARTTLS) 和隐式 TLS (SMTPS) 提供逐跳而非端到端安全性，即中间的每个邮件服务器都可以访问未加密的邮件。
• 邮件的下一跳是通过 DNS 查找 MX 记录来确定的。除非使用 DNSSec，否则这可能会被欺骗，但大多数情况下并非如此。如果它被欺骗，即使在 TLS 握手中正确检查证书也无济于事，因为它会检查到错误 MTA 的连接是否正确。
• MX 仅定义为在端口 25 上使用服务器，即使用显式 TLS (STARTTLS)。由于发送 MTA 无法知道接收 MTA 是否甚至支持 STARTTLS，因此中间人攻击者可以通过修改对 EHLO 命令的回复中支持的扩展名列表来将连接简化为普通连接或通过拒绝 STARTTLS 命令。并且即使是无法直接拦截连接的黑客，也可能会在 TLS 握手开始时注入 TCP RST 数据包，以便客户端认为使用 TLS 存在问题，并会回退到纯文本。由于 TLS 握手实际上存在足够多的实际问题，因此客户端可能不会怀疑。
• 并且在 TLS 握手中通常没有进行适当的验证。有时根本不检查证书，有时只检查链，但如果主机名匹配等则不检查。但同样，如果 MX 已经被欺骗，验证可能会针对错误的服务器进行:(

这意味着至少要使逐跳加密足够安全，您必须向多个地方添加重要的修复程序，并且其中大多数都不受发送 MTA 的控制。

要详细了解评论中的问题：

1.) STARTTLS 通常是在服务器之间实现还是从客户端-服务器开始并逐跳进行？

必须在每一跳 (MTA) 上实施 STARTTLS。仅当接收 MTA 确实支持 STARTTLS 并且发送 MTA 可以支持时才可以使用它。它不依赖于邮件如何从客户端传送到初始跃点 (MTA)。通常，带有 SMTP 的 TLS 仅加密跃点之间的连接，因此如果它也未进行端到端加密（使用 PGP 或 S/MIME），则可以在每个跃点上清晰读取。

2.) 用 PGP 或 S/MIME 加密的邮件是否仍能被 MX 欺骗重定向？

是的，它仍然可以重定向。但是邮件本身仍然只能由真正的收件人解密，即目标密钥的所有者。

3.) DNSSEC 是否必须广泛采用才能有用，还是个人可以通过在自己的电子邮件服务器上进行配置而受益？

每一点都有帮助，但只有一点点。请注意，它不仅需要 DNSSec 记录，而且转发 MTA 必须实际使用 DNSSec。大多数 MTA 可能只执行 DNS，并且没有意识到他们是否获得了欺骗性的 MX 记录。

4.) 您是否必须担心隐式 tls 或显式的 TCP RST 注入？

隐式 TLS 仅用于从客户端到 MTA，即到初始跃点。这是最安全的步骤，因为它实际上由客户端控制，并且客户端通常使用具有固定 TLS 设置的固定 SMTP 服务器，因此没有 MX 欺骗和连接降级的问题。如果客户端被配置为仅在可用时使用 TLS，则攻击也可能对隐式 TLS 起作用。

5.) 如果其他 MTA 与 TLS 不兼容，即从机会主义切换到必需，或者您只能在客户端（例如 Thunderbird）上执行此操作，则您不能将服务器/MTA 配置为断开连接（退回电子邮件）客户端 - 服务器连接？

大多数服务器都可以通过这种方式进行配置，但大多数服务器必须与各种服务器进行通信，并且他们不知道服务器是否支持 TLS。但是，例如可以将 sendmail 配置为仅与特定服务器对话 TLS 或不与特定其他服务器对话 TLS。因此，可以将此配置强化到已知良好的服务器，但这必须手动完成。

6.) 如果#5 是可能的并且电子邮件被退回，发件人会收到“发送失败”通知吗？

是的，通常就是这种情况，就像所有交付错误一样。但与大多数其他仅在技术上适合的交付错误一样，人们可能会理解这些错误消息。

7.) 至于没有得到检查的证书，是否可以通过适当的配置/实施来修复。我读到其中一个问题是许多证书都是自签名的，并且大多数 MTA 默认接受它们，因此它们可以与更多 MTA 保持兼容。那是你所指的那一部分吗？

这取决于服务器。后来我看起来 postfix 很好，但是 sendmail 无法根据证书正确检查主机名。是的，自签名是一个问题，另一个主要问题是缺少中间证书。但是由于邮件传递仍然有效（因为发件人忽略了证书错误），大多数管理员没有意识到错误的配置或不在乎。

8.) 最后，说所有重要的修复都已到位，我知道其他 MTA/客户端不在我的控制范围内。这些 MITM 和注入攻击是否可以针对进出我的电子邮件地址的特定连接？在这种情况下，他们没有闯入我的服务器，他们以前也没有接触过我的联系人。

同样，这只是逐跳加密，并且邮件在每个跃点上都可以明文读取和修改。因此，在传输中涉及的任何跃点上的攻击者（通常至少有两个，一个在发送方，一个在接收方站点）可以拦截并修改邮件，当然可以限制自己只处理选定的邮件。唯一的保护是使用 PGP 或 S/MIME 的端到端加密。