← RFC Reference

TLS和电子邮件安全

TLS 如何保护传输中的电子邮件 — STARTTLS、隐式 TLS、MTA-STS、DANE、TLSRPT — 以及为什么机会性加密还不够。

问题：SMTP 生来就是未加密的

SMTP 在 1982 年设计（RFC 821）时是明文协议。每个命令、每个响应、每个报头、每个字节的消息内容都在网络上不加密传输。通过 AUTH 发送的密码实际上是在房间里大声喊出来的。

TLS（传输层安全）被添加到 SMTP 上以解决这个问题。但与 HTTPS 不同（其中 TLS 是强制的且普遍的），电子邮件 TLS 已经通过一系列不完美的妥协发展而来，这些问题今天仍在解决中。

STARTTLS：机会性加密

STARTTLS（RFC 3207）将现有的明文 SMTP 连接升级到 TLS。流程：

关于 STARTTLS 的要点：

• 连接以明文开始并在中间升级。初始 EHLO 和 STARTTLS 命令本身是未加密的。
• STARTTLS 完成后，客户端必须再次发送 EHLO。服务器可能会在加密连接上宣布不同的功能。
• STARTTLS 在端口 25（服务器到服务器）和端口 587（客户端提交）上使用。
• 端口 25 上的 STARTTLS 默认是机会性的：如果服务器未宣布 STARTTLS，或者 TLS 握手失败，大多数发送 MTA 会回退到明文并无论如何都发送消息。

STARTTLS 剥离攻击

因为 STARTTLS 以明文开始，中间人攻击者可以修改服务器的 EHLO 响应以删除 STARTTLS 公告。发送 MTA 认为服务器不支持 TLS 并以明文继续。然后攻击者可以读取和修改消息。

这不是理论上的攻击。已在野外观察到它，特别是在进行大规模监视的国家。机会性 STARTTLS 对主动攻击者提供不了保护 — 它只保护被动窃听。

隐式 TLS：从第一个字节开始加密

RFC 8314 建议为邮件提交（客户端到服务器）使用隐式 TLS。连接从第一个字节开始就是 TLS，而不是从明文开始并升级。

• 端口 465：消息提交的隐式 TLS。客户端立即打开 TLS 连接。无需 STARTTLS 步骤。无剥离机会。
• 端口 993：IMAP 的隐式 TLS。
• 端口 995：POP3 的隐式 TLS。

RFC 8314 明确声明没有 TLS 的明文 SMTP 提交在端口 587 上已过时，隐式 TLS 在端口 465 上是首选的提交路径。实际上，端口 587 带 STARTTLS 仍被广泛部署，但方向很明确：隐式 TLS 是未来。

但是，隐式 TLS 只适用于提交路径（您的客户端到您的服务器）。端口 25 上的服务器到服务器传递仍然使用 STARTTLS，因为没有通用部署的机制让服务器预先知道收件人的 MX 支持隐式 TLS。这就是 MTA-STS 和 DANE 的用途。

MTA-STS：基于策略的 TLS 强制

MTA-STS（RFC 8461）通过允许域发布策略来解决 STARTTLS 剥离问题，该策略说"向我的 MX 服务器传递邮件时始终需要 TLS"。策略通过 HTTPS（而非 DNS）发布，这通过网络 PKI 提供了自己的身份验证。

MTA-STS 如何工作

1. 域发布 DNS TXT 记录表示存在 MTA-STS 策略：

2. 发送 MTA 通过 HTTPS 从知名 URL 获取策略：

3. 策略文件指定模式和有效的 MX 主机名：

4. 发送 MTA 缓存策略（max_age 秒）并在所有未来连接上强制执行。它将：
   • 要求端口 25 上的 STARTTLS（永不回退到明文）
   • 根据 MX 主机名验证服务器的 TLS 证书
   • 仅向策略中列出的 MX 主机名传递

MTA-STS 模式：

• enforce：需要 TLS 和有效的证书。如果无法建立 TLS，则传递失败。
• testing：尝试 TLS 但如果失败则无论如何都传递。通过 TLSRPT 发送失败报告。
• none：无策略。用于显式撤销之前的策略。

MTA-STS 具有与网络相同的信任模型：它依赖于证书颁发机构。如果 CA 被破坏，攻击者可能会伪造您的 MX 的证书。DANE 提供了一种基于 DNSSEC 的替代信任模型。

DANE：基于 DNS 的证书验证

DANE（RFC 7672）使用 DNSSEC 签名的 TLSA 记录将 TLS 证书（或其公钥）直接与 MX 主机名关联。这消除了对证书颁发机构的依赖。

TLSA 记录字段：

• 3（证书用法）— 域颁发的证书（不需要 CA）
• 1（选择器）— 对主题公钥匹配
• 1（匹配类型）— 公钥的 SHA-256 哈希
• a]b2c3d4e5f6... — 哈希值

DANE 如何为电子邮件工作

1. 发送 MTA 解析 MX 记录并获取 mx1.example.com。
2. 它查询 _25._tcp.mx1.example.com 处的 TLSA 记录。
3. 如果存在 DNSSEC 验证的 TLSA 记录，MTA 知道：
   • TLS 是强制的（不回退到明文）。
   • 服务器的证书必须与 TLSA 记录匹配。
4. MTA 连接，执行 STARTTLS，并针对 TLSA 记录而不是（或除了）CA 系统验证服务器的证书。

DANE 的优势：它不依赖于证书颁发机构。其劣势：它需要 DNSSEC，许多域未部署它。没有 DNSSEC，TLSA 记录不可信（可以操纵 DNS 的攻击者也可以操纵 TLSA 记录）。

DANE 与 MTA-STS

两种机制可以共存。域可以发布 MTA-STS 和 DANE 策略。支持 DANE 的发送者使用它；不支持的可以回退到 MTA-STS。

TLSRPT：TLS 报告

SMTP TLS 报告（RFC 8460）让域从发送服务器接收有关 TLS 连接失败的报告。它是 TLS 等效的 DMARC 汇总报告。

支持 TLSRPT 的发送 MTA 将发送详细以下内容的日常 JSON 报告：

• 到您的 MX 的总连接尝试数
• 成功的 TLS 协商
• 失败的 TLS 协商（以及原因：证书错误、STARTTLS 失败、MTA-STS 策略违反）
• 回退到明文的连接

TLSRPT 在 MTA-STS 部署期间必不可少。在 MTA-STS 策略中以 mode: testing 开始并监视 TLSRPT 报告。当您看到零个（或可接受的）失败时，转到 mode: enforce。

证书管理

TLS 需要证书，证书管理是电子邮件安全中最常见的操作失败点之一。

邮件服务器的证书

• 证书必须与 MX 主机名匹配。如果您的 MX 记录指向 mx1.example.com，证书必须对 mx1.example.com 有效。example.com 或 www.example.com 的证书将无法工作。
• 使用来自公共 CA 的证书。Let's Encrypt 对邮件服务器完美有效。自签名证书会导致检查的发送者的 TLS 验证失败（包括任何使用 MTA-STS 或 DANE 的人）。
• 自动化更新。证书过期是最常见的 TLS 失败。使用 ACME（Let's Encrypt）或您的 CA 自动化来确保证书在过期前充分更新。
• 包括所有 MX 主机名。如果您有多个 MX 服务器，每个都需要其主机名的有效证书。SAN（主题备用名称）证书可以覆盖多个主机名。

证书错误及其影响

这个表揭示了机会性 TLS 的核心问题：没有 MTA-STS 或 DANE，大多数证书错误被无声地忽略。连接是加密的，但未认证 — 您可能正在将消息加密到攻击者的服务器。

电子邮件加密的现状

电子邮件加密存在于两个级别，经常被混淆：

传输加密（TLS）

TLS 加密服务器之间的连接。它在消息在任何两点之间传输时防止窃听。消息到达目标服务器后，被解密并以明文存储（通常）。TLS 保护传输，而不是消息。

传输加密是逐跳的：消息在您的服务器和下一个服务器之间加密，然后解密，然后为下一跳重新加密。每个中间服务器都可以访问明文消息。

端到端加密（S/MIME、PGP）

端到端加密（RFC 8551 中的 S/MIME，或 PGP/OpenPGP）加密消息内容本身，因此只有具有正确私钥的预期收件人可以解密它。消息在服务器上保持加密状态并在每个传输跳期间加密。

端到端加密在电子邮件中的采用仍然极其低。原因是实际的：

• 密钥管理很困难。发送者和收件人都必须管理密钥。没有通用密钥目录。
• 可用性差。大多数电子邮件客户端使加密繁琐。普通用户不能（也不应该需要）管理 PGP 密钥。
• 服务器端功能受损。如果服务器无法读取消息，它无法索引它、搜索它、过滤垃圾邮件或应用规则。
• 互操作性受限。S/MIME 和 PGP 彼此不兼容。

对于大多数电子邮件，传输级 TLS 是实际的加密层。端到端加密仍然是利基，在操作负担合理的高安全环境中使用。

需要 TLS（RFC 8689）

RFC 8689 定义了一个按消息机制来需要 TLS。发送者向各个消息添加 REQUIRETLS SMTP 扩展：

当设置 REQUIRETLS 时：

• 接收服务器必须使用 TLS 传递或中继消息。如果 TLS 在下一跳不可用，消息被反弹而不是以明文发送。
• TLS 证书验证必须成功。
• 所有下游跳跃也必须支持并遵守 REQUIRETLS。

REQUIRETLS 是消息级别的 — 您可以为敏感消息使用它，而无需为所有邮件需要 TLS。但是，采用仍然有限。大多数服务器还不支持它。

实用部署指南

这是为您的域的电子邮件部署 TLS 的推荐序列：

步骤 1：确保您的 MX 服务器上的 TLS

从公共 CA 获取每个 MX 主机名的有效证书。自动化更新。测试来自外部发送者的 STARTTLS 是否正确工作。

步骤 2：部署 TLSRPT

发布 _smtp._tls TXT 记录以接收 TLS 失败报告。在强制任何东西之前开始监视。

步骤 3：在测试模式下部署 MTA-STS

发布 DNS TXT 记录和带有 mode: testing 的 HTTPS 策略文件。监视 TLSRPT 报告中的失败。调查并修复任何问题。

步骤 4：将 MTA-STS 移动到强制模式

一旦 TLSRPT 报告显示清晰的结果，将模式更改为 enforce。增加 DNS TXT 记录中的 id 以表示策略更改。

步骤 5：考虑 DANE（如果您使用 DNSSEC）

如果您的域是 DNSSEC 签名的，为您的 MX 服务器发布 TLSA 记录。这提供了独立于 CA 系统的额外层证书固定。

可能出错的地方

过期的证书导致传递失败

您的 MX 服务器的证书过期了。没有 MTA-STS，大多数发送者忽略错误并无论如何都传递（不安全但可工作）。有了 MTA-STS 在强制模式中，验证证书的发送者将延迟传递。消息在发送方排队。如果您在发送者的重试窗口内（通常 4-5 天）不修复它，消息会反弹。修复：使用 Let's Encrypt/ACME 自动化证书更新。

MX 更改后的 MTA-STS 策略不匹配

您添加了新的 MX 服务器 (mx3.example.com)，但忘记将其添加到 MTA-STS 策略文件。已缓存旧策略的发送者拒绝与新 MX 的连接，因为它不在策略的允许列表中。修复：在添加新 MX 记录之前始终更新 MTA-STS 策略文件，并增加策略 DNS 中的 id。

未检测到的 STARTTLS 剥离

没有 MTA-STS 或 DANE，攻击者从服务器的 EHLO 响应中剥离 STARTTLS。消息以明文传递。发送者和接收者都不知道。修复：部署 MTA-STS 使 TLS 剥离可检测和可防止。

DANE TLSA 记录变陈旧

您轮转 TLS 证书但忘记更新 DNS 中的 TLSA 记录。验证 DANE 的发送者看到不匹配并拒绝传递。修复：始终在部署新证书之前更新 TLSA 记录。使用协调证书部署与 DNS 更新的自动化。

关键要点

• 机会性 STARTTLS 比没有好，但对主动攻击提供不了保护。可以修改网络流量的攻击者可以从连接中剥离 TLS。
• MTA-STS 防止 TLS 剥离通过发布发送者缓存和强制的策略。它依赖网络 PKI（证书颁发机构）。
• DANE 防止 TLS 剥离通过在 DNSSEC 签名的 DNS 记录中发布证书数据。它不依赖 CA 但需要 DNSSEC。
• 如果可能，两者都部署。MTA-STS 有更广泛的发送者支持；DANE 更强但需要 DNSSEC。一起他们覆盖最多的地方。
• TLSRPT 对可见性必不可少。没有它，您不知道对您的域的入站邮件 TLS 失败的频率。
• 证书管理是操作关切。自动化更新。将证书与 MX 主机名匹配。协调证书轮转与 DANE TLSA 更新。
• TLS 保护传输，而不是内容。对于端到端消息加密，您需要 S/MIME 或 PGP — 但可用性和采用障碍仍然很高。
• 隐式 TLS（端口 465）是提交的未来。对于服务器到服务器传递，带 MTA-STS/DANE 强制的 STARTTLS 是当前最佳实践。

延伸阅读

Related RFCs