TLS-RPT、DANE 和 MTA-STS

出自 ArchWiki

我们信任电子邮件的方式有两个关键要素。一个是如何验证邮件的内容和发件人，包括消息加密以及 DMARC (RFC 7489)、DKIM (RFC 6376)、SPF (RFC 7208) 和 ARC (RFC 8617)。另一个是关于对邮件服务器本身的信任，而这正是本文要讨论的内容。

根据 RFC 3207，公开可访问的电子邮件服务器需要能够在没有 TLS 加密的情况下被访问。这使得服务器容易受到降级攻击，从而进行明文传输。此外，实际上证书不需要满足任何有效性要求，因为 RFC 3207 没有指定任何要求。为了防止这种情况，出现了两种技术，并且越来越多的主要电子邮件提供商也支持它们：DANE 和 MTA-STS。这两种技术都告知电子邮件发送者 TLS 可用，并且不应使用明文进行传输。它们也都以自己的方式验证所提供的证书。还存在一个名为 TLS-RPT 的附加协议，该协议允许将与 TLS 配置相关的任何问题通知给电子邮件服务器的运营商，从而防止电子邮件无法到达目的地。本文解释了如何部署这三种技术。

请注意，如果可能，MTA-STS 和 DANE 应该一起部署，而不是只部署其中一个。它们的设计目的不是相互干扰，并且邮件发送者对两者的支持程度各不相同。正如本文后面讨论的那样，Postfix 和 Exim 没有内置 MTA-STS 支持。任何使用其中任何一个的发送者只能使用 DANE，除非完成一些额外的工作（见下文）。同样，DANE 需要 DNSSEC，并非每个邮件提供商都支持此扩展。目前，世界上最大的电子邮件提供商 Google Mail 不使用 DANE 或 DNSSEC，而完全依赖 MTA-STS。

当使用 MTA-STS 时，TLS 证书需要来自有效的证书颁发机构，并且当前对电子邮件服务器的主机名有效。另一方面，DANE 依赖于利用 DNSSEC 来提供证书的真实性。但是，DANE 需要发送者使用 DNSSEC 验证 DNS 解析器，并且在入站方向上，域需要注册 DNSSEC。这对于每个 DNS 注册商来说可能并非都可行。在这种情况下，入站方向只能使用 MTA-STS，但它仍然可以与 TLS-RPT 一起使用。当结合使用这两种技术时（如建议的那样），所提供的证书可以由其中任何一个验证，因此需要具有 DANE 的当前 DNS 记录并且由受信任的根 CA 签名。

德国国家安全标准 BSI TR-03108 强制要求同时使用所有三种机制，这通常被认为是良好的实践。

入站

在本节中，讨论入站方向，也就是说，设置允许其他邮件服务器向您的服务器发送邮件。

MTA-STS

邮件传输代理 - 严格传输安全 (MTA-STS) 是一种技术，允许邮件服务器声明其接收传输层安全 (TLS) 连接的能力。它还提供指定策略，该策略请求发送 SMTP 服务器在接收服务器未提供受信任的服务器证书时应拒绝传递，或不传递。

注意： RFC 3207 仅表示客户端和服务器应确保在建立 TLS 连接时“实现了可接受程度的身份验证和隐私”。特别是，它没有指定任何类型的验证，例如证书是否由受信任的 CA 颁发、证书是否与服务器匹配或证书是否通过了吊销检查。当使用 MTA-STS 时，RFC 8461 第 4.2 节确实要求进行验证，并且强制客户端确保证书由受信任的根 CA 签名、未过期并且具有与服务器主机名匹配的主题备用名称 (SAN)。吊销检查留给客户端但允许进行，因此证书需要处于良好状态。

MTA-STS 的工作原理是发布 DNS 条目并在 https://mta-sts.<domain>/.well-known/mta-sts.txt 托管策略文件。

DNS 条目是在 _mta-sts.<domain> 发布的 TXT 记录。它的形式如下

v=STSv1; id=202408090200Z

v=STSv1 字段是已部署的 MTA-STS 的修订版本，目前为 1。id 是一个包含 1-32 个字符的字母数字字段。每次增加它时，MTA-STS 策略都被认为已更改。良好的实践是创建一个表示当前日期的字符串，并在策略发生任何更改时更新它。

最后，策略是一个如下类型的文本文件

version: STSv1
mode: enforce
max_age: 10368000
mx: mail.example.org
mx: *.example.org

有三种不同的模式

none
通知发送者没有策略，这实际上禁用了 MTA-STS
testing
意味着该策略应被视为非活动状态，但仍应生成 TLS-RPT 报告。仅当已配置 TLS-RPT 时，此模式才有意义。
enforce
是告知发送者如果无法通过 TLS 建立连接，则拒绝连接到服务器的模式。

max_age 是策略的生命周期，以秒为单位。这应该在几周到一年之间，但少于 31557600 秒（大约一年）。mx 字段只需列出域的所有 MX 记录。

DANE

警告： DANE 要求域注册 DNSSEC。否则它无法工作。

DANE 是 基于 DNS 的命名实体身份验证 的缩写。它是一种安全协议，使用 DNS 来验证与域名关联的数字证书的真实性。它被设计为证书颁发机构（例如 Letsencrypt）的替代方案，通过利用 DNSSEC 的完整性来确保证书确实属于域名。虽然 DANE 适用于任何证书，但在实践中它仅用于电子邮件，或 DANE SMTP。按照设计，私钥和证书可以自行生成。虽然使用 CA 提供的证书也可以，但这根本不是必需的，它们也没有提供任何显着的好处。DANE 的一个关键目标是防止中间人攻击。DNSSEC，或 域名系统安全扩展，是保证通过 DNS 发布的公钥完整性的技术，因此没有它就无法使用 DANE。

本节重点介绍如何将 DANE 专门用于 SMTP。How to create a DANE TLSA record with OpenSSL 是关于与 DANE 相关的所有内容的更全面的指南。

DANE 的工作方式是利用 DNSSEC 在 DNS 中以特殊 TLSA 记录的形式发布证书的哈希值。对于电子邮件，有两个可用的选项

DANE-TA
发布签署电子邮件服务器使用的 TLS 证书的证书颁发机构的证书。例如，如果使用 Let's Encrypt 服务，这将是 Let's Encrypt 的根证书。
DANE-EE
通过发布电子邮件服务器本身使用的证书的哈希值来工作。

可以发布整个证书或仅发布嵌入其中的公钥。后一种选择允许重用证书的密钥对，从而永远不必更改 DNS 条目。当发布整个证书时，每次证书颁发机构颁发新证书时，都必须更新 TLSA 记录。如果 ACME 与例如 Let's Encrypt 一起使用，这种情况可能会非常频繁地发生。

警告： 重用密钥对被认为比使用更改密钥对稍微不安全。

TLSA 记录由三个数字字段和证书数据组成。例如，它可能看起来像这样

_25._tcp.mail.example.org
3 1 1 3a8a378f19eef5c90f783ba44f8d0e8648e883926b16f1dfaf94eef9e1602531

记录名称的格式为 _[port]._[protocol].[service url]。对于 SMTP，这意味着端口为 25，协议为 TCP。

数字字段如下

  1. 第一个字段是正在使用的 DANE 的类型，称为证书用途字段。值为 2 表示 DANE-TA，3 表示 DANE-EE。值 0 和 1 不适用于电子邮件，并且 不应使用。
  2. 第二个字段，称为选择器字段，指示是发布完整证书 Cert(0) 还是仅发布证书的公钥 SPKI(1)。
  3. 第三个字段称为匹配类型字段，指示数据的发布方式。值为 1 是 SHA2-256 哈希值。其他可能的选项通常被认为不适用于实际目的，因此在此不作讨论。
注意： RFC 7672 建议使用 “DANE-EE(3) SPKI(1) SHA2-256(1)” 组合，并将 “DANE-TA(2) Cert(0) SHA2-256(1)” 作为第二选择。
注意： 在 DANE-EE 记录中使用完整证书或仅使用公钥没有安全隐患。两种选择都没有特别的优势，除了 SPKI(1) 允许在重新颁发证书时重用密钥对。当使用 SPKI(1) 时，DNS 记录在证书重新颁发时不需要任何更改。对于 DANE-TA，RFC 6698 附录 A.1.2.2 和 RFC 7672 第 3.1.2 节 讨论了该选择。建议将匹配类型 Cert(0) 与 DANE-TA 一起使用。否则，中间 CA 可能重新颁发其证书，使用不同的证书内容和相同的密钥对。在这种情况下，可能会违反证书约束。

最后，数据字段将分别是证书或公钥的 SHA2-256 哈希值。为了计算这个值，可以使用 openssl。

Hashing the full certificate (option 0)
openssl x509 -in certificate.pem -outform DER | sha256sum
Hashing the public key only (option 1)
openssl x509 -in certificate.pem -pubkey -noout | openssl ec -pubin -outform der | sha256sum

在 DANE-EE 的情况下，certificate.pem 将是电子邮件服务器使用的实际 TLS 证书。另一方面，对于 DANE-TA，这必须是任何颁发 CA 的证书。

注意： 可以使用匹配类型 2 以使用 SHA2-512 而不是 SHA2-256。不建议这样做，因为 RFC 6698 使 SHA2-512 支持的实现成为可选的，并非所有解析器都可能支持它。RFC 7672 也对此表示不鼓励，并建议改用 SHA2-256 TLSA 记录。
警告： 就其本身而言，DANE-EE 可以与自签名或不受信任的证书甚至过期的证书一起部署。同样，DANE-TA 可以与任何 CA 一起使用。但是，由于 MTA-STS 对所提供的证书提出了要求，因此当同时部署这两种技术时，必须提供满足上述要求的有效证书，因为允许发送者使用其中任何一种。

根据 DNS 提供商的不同，可能可以自动执行此记录的发布。gotlsaflareAUR 例如，允许将记录发布到 Cloudflare DNS 服务。鉴于存在大量的提供商，因此无法为此步骤提供任何具体说明。

警告： 由于 DNS 记录会被缓存一段时间（由 TTL 给出），因此更新 TLSA 记录必须分步完成，首先添加新记录，等待 TTL 超时，然后最终删除之前的记录并将邮件服务器切换到新证书。

TLS-RPT

SMTP TLS 报告 (TLS-RPT) 在 RFC 8460 中定义，是用于报告与 TLS 加密失败和成功连接相关的邮件传递问题的标准。

TLS-RPT 的工作原理是发布 DNS 记录，告知发送者将关于 TLS 功能的报告发送到哪里。只有一种类型的报告，即聚合报告，它总结了特定结果（无论是错误还是成功）发生的频率。它被格式化为 XML 文件，以便进一步处理。

TLS-RPT 记录是在 _smtp._tls.[domain] 发布的 TXT 记录。内容必须以版本指示符 v=TLSRPTv1; 开头，后跟有关报告发送位置的信息。这可以是邮件地址或接受 POST 请求的 HTTPS 服务。完整的记录如下所示

_smtp._tls.example.org
v=TLSRPTv1; rua=mailto:tlsrpt@example.org

rua 指示聚合报告将发送到此地址，mailto: 指定应通过邮件完成。https: 将是 HTTPS POST 解决方案的前缀。

警告： 强烈建议不要使用 HTTPS POST 端点进行报告。BSI TR-03108 实际上禁止这样做。虽然可以使用 DMARC 对电子邮件进行身份验证，但 HTTPS POST 机制不能。攻击者可能会发送欺诈性报告，试图掩盖干扰。

由于报告是 XML 格式的，因此建议处理它们以提取信息。还有许多云服务提供商可以接收和处理这些报告。tls-rpt 也可在 dmarc_reportAUR 软件包中找到，该软件包可以从 XML 文件为 DMARC 和 TLS-RPT 生成人类可读的报告。有关此方面的更多信息，请参阅 dmarc_report Readme

出站

接下来，讨论出站方向（即发送电子邮件时）。与入站方向不同，在入站方向中，所有三种技术都主要独立于所使用的邮件传输代理，出站方向的步骤因所使用的邮件服务器而异。

所有 MTA 的一个共同点是，为了发送 TLS-RPT 报告，处理出站邮件的所有邮件服务器都需要支持 RFC 8689 扩展，因为 TLS-RPT 报告必须使用标头 Require-TLS: no 发送。

此外，解析 DANE 需要能够处理 DNSSEC 的 DNS 解析器，并且强烈建议 MTA-STS 也使用，因为否则 连接可能被降级。以下各节假设 DNSSEC 正用于 DNS，并且每次都不会重复这一点。

Postfix

Postfix 早已支持 DANE（自 Postfix 2.11 起），但 MTA-STS 和 TLS-RPT 依赖于插件。

注意： TLS-RPT 和 RFC 8689 仅在 Postfix 3.10 及更高版本中受支持。为了发送报告，Postfix 设置中的所有出站邮件服务器都需要至少在该版本上。

DANE

DANE 内置于 Postfix 中，只需要将以下行添加到 /etc/postfix/main.cf

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

MTA-STS

为了支持 MTA-STS，需要一个插件通过 smtp_tls_policy_maps 向 Postfix 提供有关 TLS 策略的信息。对此，有两个可用的选项，postfix-tlspol 和 postfix-mta-sts-resolverAUR。

注意： postfix-mta-sts-resolverAUR 面临一个问题，即它无法解析 DANE，因此如果在服务器上同时部署 MTA-STS 和 DANE，它会覆盖 DANE。该项目在 此处 讨论了这个问题。postfix-tlspol 没有这样的限制，并且也经过了更好的优化。

安装 postfix-tlspol 并 启动 或 启用 postfix-tlspol.service。然后编辑 Postfix 的 /etc/postfix/main.cf 以添加以下行

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_policy_maps = socketmap:inet:127.0.0.1:8642:QUERYwithTLSRPT
注意： postfix-tlspol 同时解析 MTA-STS 和 DANE，因此也需要启用 DANE 和 DNSSEC。

TLS-RPT

注意： 为了使 TLS-RPT 有用，至少必须已经配置 DANE 或 MTA-STS（理想情况下两者都配置）。

安装 tlsrpt-reporter。至少调整 /etc/tlsrpt/reportd.cfg 中的以下行以适合您的域和组织

organization_name = EXAMPLE.COM
contact_info = tlsrpt@EXAMPLE.COM
sender_address = noreply@EXAMPLE.COM

之后，启动 或 启用 tlsrpt-collectd.service 和 tlsrpt-reportd.service。然后，将以下行添加到您的 Postfix /etc/postfix/main.cf

smtp_tlsrpt_enable = yes
smtp_tlsrpt_socket_name = /run/tlsrpt/tlsrpt-collectd.socket
注意： 可以在不同的系统上运行 tlsrpt-collectd.service 和 tlsrpt-reportd.service。请考虑 tlsrpt-reportd(1) 中的 fetcher 选项。
警告： 当前存在 一个问题，如果 tlsrpt-collectd.service 至少一天没有运行，则会导致 tlsrpt-reportd.service 输出重复错误。这不影响功能，并且已在 上游修复，因此应在下一个版本中解决。

Exim

Exim 仅支持 DANE，不支持 MTA-STS 或 TLS-RPT。为了激活 DANE，编辑 /etc/exim/exim.conf 并添加

dns_dnssec_ok = 1

此外，编辑 remote_smtp 传输并在其中添加以下行

hosts_try_dane = *

有关此主题的更多信息，请参阅 Exim 文档 此处。

Stalwart

Stalwart 已经内置了 DANE、MTA-STS 和 TLS-RPT 这三种技术。请参阅他们的文档 此处 以获取有关如何启用和配置它们的说明。

检索自“https://wiki.archlinux.org.cn/index.php?title=TLS-RPT,_DANE_and_MTA-STS&oldid=827970”