← RFC Reference

DANE — 基于DNS的SMTP TLS身份验证

为什么存在这个

SMTP 和 STARTTLS 有两个根本问题:

1. 没有身份验证。发送服务器无法可靠地验证接收服务器的 TLS 证书是否合法。SMTP 不使用网络的 CA 信任模型 — 历史上，大多数邮件服务器使用自签名证书，所以发送者学会了接受任何证书。
2. 降级攻击。主动网络攻击者可以从 EHLO 响应中删除 STARTTLS 广告，强制使用明文投递。

MTA-STS (RFC 8461) 使用 HTTPS 和 Web PKI 解决这些问题。DANE 使用 DNSSEC 和 TLSA 记录解决它们。这两种方法是互补的：DANE 在密码学上更强大（不需要 CA 信任），而 MTA-STS 更容易部署（不需要 DNSSEC）。

工作原理

SMTP 的 DANE（在 RFC 7672 中定义，基于 RFC 6698 中的基础 DANE 规范）分三个步骤工作：

第 1 步：DNSSEC 签名区域

接收域的 DNS 区域 — 以及 MX 目标的区域 — 必须用 DNSSEC 签名。这是不可协商的。没有 DNSSEC，攻击者可以伪造 TLSA 记录，使 DANE 比没有还糟。

第 2 步：发布 TLSA 记录

该域为每个 MX 主机的 SMTP 端口发布 TLSA 记录。TLSA 记录将 TLS 证书（或其公钥，或其 CA）绑定到特定服务。

TLSA 记录字段

第 3 步：发送者验证

当支持 DANE 的发送服务器向 example.com 投递邮件时：

1. 使用 DNSSEC 验证解析 example.com 的 MX 记录。
2. 对于每个 MX 主机（例如 mail.example.com），使用 DNSSEC 验证查询 _25._tcp.mail.example.com TLSA。
3. 如果存在 DNSSEC 验证的 TLSA 记录：连接，执行 STARTTLS，并根据 TLSA 数据验证服务器证书。
4. 如果验证失败：不投递。邮件排队等待重试。
5. 如果不存在 TLSA 记录（或未部署 DNSSEC）：回退到之前的机会性 TLS。

关键技术细节

推荐的 TLSA 配置

对于 SMTP 服务器，RFC 7672 推荐 DANE-EE(3) SPKI(1) SHA-256(1)：

这是最健壮的选择，因为：

• 使用 3 (DANE-EE) 完全绕过 CA 验证。证书不需要由公共 CA 签名 — 自签名证书也可以。
• 选择器 1 (SPKI) 匹配公钥，而不是完整证书。只要密钥对保持不变，你可以更新证书（更改序列号、有效期），而无需更新 TLSA 记录。
• 匹配类型 1 (SHA-256) 存储哈希而不是完整密钥，使 DNS 记录保持精简。

生成 TLSA 记录

# 提取服务器公钥的 SHA-256 哈希
openssl x509 -in server.crt -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -hex
(stdin)= 2a9f8e3b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f

# 生成的 TLSA 记录：
_25._tcp.mail.example.com. IN TLSA 3 1 1 2a9f8e3b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f

DANE vs. MTA-STS

常见错误

• 发布 TLSA 记录而不使用 DNSSEC。如果你的区域未用 DNSSEC 签名，TLSA 记录会被忽略。更糟的是，某些实现可能会将未签名的 TLSA 作为信号，表示不要求 TLS，降低安全性。
• 忘记在密钥轮换时更新 TLSA。如果你使用选择器 0（完整证书）并使用新密钥更新证书，TLSA 记录必须在新证书生效前更新。使用选择器 1 (SPKI) 并在更新中保持相同的密钥对，以避免这种情况。
• 在域上放置 TLSA，而不是在 MX 主机上。TLSA 记录应放在 MX 目标主机名上（例如 _25._tcp.mail.example.com），而不是在域本身上。如果你的 MX 指向第三方主机，TLSA 记录必须在他们的区域中。
• 错误地轮换 TLSA 记录。轮换密钥时，同时发布新旧密钥的 TLSA 记录。仅在证书轮换后且 DNS 缓存过期后，才删除旧记录。
• 忽视 DNSSEC 信任链。从根到 TLSA 记录的链中的每个区域都必须用 DNSSEC 签名。链中任何地方的中断都会使整个链失效。

可投递性影响

• 最强 TLS 保证。DANE 单独从 DNS 提供服务器身份的密码学证明。没有 CA 妥协，没有 TOFU 窗口 — 从第一次连接开始安全。
• 在欧洲广泛部署。荷兰、德国和捷克对政府和机构邮件有高 DANE 采用率。如果你向这些地区投递，DANE 支持是一个显著优势。
• Postfix 原生支持。Postfix 内置 DANE 支持（smtp_tls_security_level = dane）。对于使用 Postfix 的发送者，当接收域有 TLSA 记录时，DANE "开箱即用"。
• 与 MTA-STS 互补。同时部署两者。支持 DANE 的发送者会使用它（保证更强）；仅支持 MTA-STS 的发送者会使用它。两者都比仅使用机会性 TLS 更好。

Related RFCs