M3AAWG 邮件中间人（MITM）攻击防御建议

引言

消息社区在推动邮件流量机会性（尽力而为）加密部署方面取得了令人瞩目的进展。然而，正如《TLS for Mail: M3AAWG Initial Recommendations》与 IETF《Opportunistic Security: Some Protection Most of the Time》文档所述，机会性加密并不足以抵御中间人（MITM）攻击。

要理解这一点，需要考察机会性加密在无法充分协商时的典型行为——MTA 到 MTA（邮件传输代理之间）的传输会降级为明文发送，即完全无加密。因此，邮件服务商只能在"容忍尽力而为加密"与"彻底放弃加密"之间做出选择。这一选择余地极为有限，本文假设机会性 TLS 是更优选项。但即便机会性加密保护了消息在传输过程中不被窥探，拥有自签名证书的 MITM 攻击者仍有可能冒充目标接收方。

这份简短文档描述了 MITM 攻击的现状及其多种实施手段，并介绍了抵御这些攻击的各层组件。同时，本文还引入了一项新技术——DANE（基于 DNS 的名称实体认证），它能够帮助消息提供者在 SSL/TLS 通信中验证自身是否在与预期目标进行通信。

缓解中间人（MITM）攻击

在 MITM 攻击中，攻击者将自己置于消息发送方与预期接收方之间。以下方法均曾被恶意行为者用于插入发送方与接收方之间的通信链路。此列表并非穷举：

1. ARP 欺骗^[1]
2. 恶意 DHCP 服务器^[2]
3. Web 缓存通信协议（WCCP）^[3]
4. Web 代理自动发现协议（WPAD）^[4]
5. 伪造 WiFi 无线接入点（"邪恶双子星"接入点）^[5]
6. DNS 投毒^[6]
7. BGP 路由注入^[7]
8. 物理（在线）网络流量截获设备

本文不讨论在终端上实施的截获攻击，也不涉及浏览器中间人（Man-in-the-Browser）攻击等类型。与任何安全技术一样，缺乏安全的端点，就无法保证整体数据安全。

MITM 攻击的风险

如果攻击者能够成功对明文网络流量实施 MITM 攻击，他们可以窃听、篡改流量或冒充通信双方。如果流量在传输过程中经过加密，但端点未获得针对 MITM 攻击的密码学保护，攻击者仍然可以对该加密流量实施与明文流量类似的多项攻击。因此，对加密传输提供 MITM 攻击防护至关重要。

在理想情况下，流量应通过用户端实施 PGP/GPG 或 S/MIME 实现端到端保护，同时服务器间流量也应通过 SSL/TLS 加以保护。但大多数用户并未使用 PGP/GPG 或 S/MIME，这使得对 MITM 攻击更具抵抗力的服务器间加密显得尤为关键。希望抵御 MITM 攻击的消息提供者可以通过以下方法来保护服务器间流量：

1. 所有邮件服务器使用全球可信证书进行身份标识——即服务器使用由全球信任的证书颁发机构（CA）签名的证书。
2. 服务器名称与证书所颁发的一个域名相对应（服务器与证书"匹配"）。
3. 已检查在线证书状态协议（OCSP）和/或证书吊销列表（CRL），证书未被吊销。
4. 证书在有效期之内使用——不在生效前使用，也不在过期后使用。
5. 证书使用行业标准的签名算法（SHA-2）签名^[8]。
6. 证书使用强密钥对（2048 位或 4096 位 RSA）。
7. 源发邮件服务器与接收邮件服务器均支持最新版本的 TLS 协议（本文发布时为 TLS 1.2）。
8. 双方服务器就支持前向保密^[9]的密码套件达成一致，用于密钥交换（通常为临时 Diffie-Hellman [EDH]^[10] 或椭圆曲线临时 Diffie-Hellman [ECDHE]^[11]）。
9. 协商使用强对称密码（首选 AES-128 或 AES-256）。

如果发送 MTA 与接收 MTA 之间不满足以上任何一项条件，发送服务器不应将消息传输至该接收 MTA。

无法安全投递消息的处理方式

如果发送服务器无法将消息传输至目标接收服务器，应如何安全处理这些无法投递的消息？可选方案包括：

1. 直接拒收并退回给发送方处理——前提是发送主机与接收主机在连接仍保持期间已达成"无法安全交换消息"的一致判定。无法安全投递的消息不得退回到消息正文中的显式发件人（否则存在伪造发件人地址的风险）。
2. 临时排队并重试一次或多次，用于处理暂时性的无法投递情况。
3. 在完成上述（1）或（2）步骤后，直接丢弃该消息。这要求发送方具备应用层面的投递确认机制，以便在发生静默丢失时能够及时发现。

通常情况下，无法投递消息的处理方式应与 M3AAWG《Sender Best Common Practices》^[12] 第 3.8 节的建议保持一致。

DANE 的未来方向

基于 DNS 的名称实体认证（DANE）^{[13, 14]} 是 IETF 提出的一种方法提案，允许证书通过 DNSSEC 绑定到 DNS 名称上。DANE 使站点可以指定其使用的证书，并要求与该站点交互的第三方"应当看到"该证书。证书的身份由 DNS 中包含的特殊记录加以指定。DNSSEC 使第三方能够信任 DNS 中发布的 DANE 记录。M3AAWG 将在后续的独立文档中更全面地探讨 DANE。

结论

按《TLS for Mail: M3AAWG Initial Recommendations》的描述部署机会性加密，是开始在服务商之间保护邮件流量的优秀起点。然而，它并非为抵御更复杂的中间人攻击而设计。M3AAWG 建议行业消息提供者遵照本文阐述的原则来对抗 MITM 攻击——即更严格地关注证书及其验证方式，将身份与密码学密钥对紧密绑定。本指南无意被视为全面方案，M3AAWG 正在制定更多指导建议以进一步改进用户消息保护。

译者补充：国内邮件 MITM 风险与部署现状

GFW 证书替换风险

在国内互联网环境中，邮件通信面临一些特殊的 MITM 风险场景。其中最为人所知的是国家防火墙（GFW）对未加密或弱加密 TLS 连接的证书替换行为。当境外邮件服务器的 TLS 证书链包含不被国内网络信任的 CA 时，GFW 可在 TLS 握手阶段注入国内信任的 CA 签发替换证书，从而实现中间人解密。这一行为在机会性 TLS（Opportunistic TLS）场景下尤为危险——因为 MTA 默认不验证证书链。M3AAWG 原文建议的证书严格验证（第 1-9 条）——即要求 CA 可信、服务器名匹配、OCSP/CRL 检查——正是阻断此类替换攻击的关键。

对于国内邮件服务商而言，推荐的做法包括：

• 证书验证强制性：将可选的 STARTTLS 配置改为强制性 TLS（MTA Strict Transport Security），确保不降级到明文。
• CA 选择策略：优先使用同时受国内和国际信任的多根 CA 证书（如国内 CA 机构 + 国际 CA 交叉签名），减少因唯一信任链断裂导致的验证失败。
• 证书固定（Certificate Pinning）：对已知通信伙伴固定特定证书或公钥，避免中间人使用替换证书建立连接。

MTA-STS 在国内的部署现状

MTA-STS（RFC 8461）通过 DNS TXT 记录和 HTTPS 策略文件声明邮件接收方支持 TLS 的策略级别。截至 2026 年，国内邮件服务商对 MTA-STS 的部署率仍处于较低水平：

• 大型云邮件服务商：部分头部服务商（如腾讯企业邮箱、阿里企业邮箱）已开始支持 MTA-STS，但策略等级多为 testing 而非 enforce——这意味着即使 TLS 协商失败，消息仍可降级到明文传输。
• 中小型邮件服务商：绝大多数尚未部署 MTA-STS。原因包括运维复杂度（需要同时维护 HTTPS 站点和 DNS 记录）、对 TLS 降级风险认识不足，以及缺乏自动化工具。
• 信创邮件系统：在党政机关和国企的信创邮件系统替代项目中，出于合规考虑，信创邮件厂商通常遵循国密标准（SM2/SM3/SM4），与 MTA-STS 的 X.509/国际 TLS 证书体系存在兼容性问题。部分信创系统通过双栈证书方案（同时部署国际 TLS 证书和国密证书）来解决。

DANE 在国内的应用前景

DANE 依赖 DNSSEC 的全局部署——而 DNSSEC 在国内的渗透率仍然偏低。截至 2026 年，.cn 顶级域中启用 DNSSEC 签名的域名比例不足 5%，且部分递归解析器对 DNSSEC 验证的支持不完整。这使得 DANE 在国内邮件场景中的实际应用受到制约。替代路径包括：

• MTA-STS + SMTP TLS Reporting（RFC 8460）：作为不依赖 DNSSEC 的轻量级方案，适合国内渐进式部署。
• SMTP STS 与 DANE 混合策略：对国际邮件优先使用 DANE，国内邮件使用 MTA-STS。