简单邮件传输协议（SMTP）用于在邮件服务器之间进行邮件传输，并且传统上是不安全的，因此容易被黑客窃听。命名实体的基于DNS的认证（国家统计局）用于SMTP提供了邮件传输更安全的方法，并逐渐变得越来越流行。
在这篇文章中，我们将讨论与SMTP相关的风险以及DANE如何克服这些风险，并为您提供Internet.nl向那些在实施DANE时照顾邮件服务器的人建议的技巧。
关键点：
- 即使安装了STARTTLS扩展程序，SMTP也有遭受中间人攻击的风险。
- DANE有助于缓解此类攻击。有关DANE实施的指南，请参见我们的操作方法。
- DANE打算在MX域上发布。因此，如果您使用的是另一个域的邮件服务器，请确保通过设置一个或多个TLSA记录来要求该域的管理员支持DANE。
使用STARTTLS的机会性SMTP的风险
默认情况下，邮件传输以纯文本格式进行。通过引入STARTTLS扩展，机会安全性已添加到SMTP协议中。这意味着仅当接收邮件服务器请求发送邮件服务器使用加密的传输层安全性（TLS）连接时，邮件服务器之间的邮件传输才受到保护。如图1所示。
图1 —尽管与传统的未加密SMTP连接相比，STARTTLS被认为是一种改进，但仍使电子邮件传输容易受到风险的影响。
尽管STARTTLS可以对邮件传输进行加密，但是不会强制执行加密，并且发送邮件服务器不会对接收邮件服务器进行身份验证。这导致以下风险。
风险1：STRIPTLS /降级攻击
首先，发送邮件服务器无法预先确定接收服务器是否支持加密传输。仅在通信开始之后，发送服务器才可以从接收服务器支持的功能（在本例中为STARTTLS）中学习允许加密传输的功能。
结果，从一台邮件服务器到另一台邮件服务器的初始连接总是开始未加密，从而使其容易受到中间人（MITM）攻击。如果邮件服务器在SMTP握手期间不提供“ STARTTLS功能”（因为它已被攻击者剥离），则邮件传输将通过未加密的连接进行。
图2-此图显示了攻击者执行MITM攻击并通过从接收电子邮件服务器中剥离TLS功能来强制建立不安全的连接时会发生的情况。当攻击者控制发送服务器和接收服务器之间的网络通信时，攻击者可能会通过删除指示接收服务器支持加密传输的信息来降级会话。发送服务器将继续处理并传输未加密的消息，从而使攻击者可以看到消息中包含的所有数据。
风险2：将邮件流量转移到攻击者的邮件服务器
其次，默认情况下，邮件服务器不会验证其他邮件服务器证书的真实性；接受任何随机证书。尽管传统上认为邮件的传递比邮件的安全性更为重要，但从技术角度来看，尚不清楚要在证书中验证哪些名称。
邮件服务器的主机名是通过DNS邮件交换器（MX）查找获得的，但是如果没有DNSSEC，这些名称将无法被信任。结果，攻击者可以将任何随机证书插入连接过程。
图3 —该图显示了攻击者执行MITM攻击并将其自己的证书插入连接过程时会发生什么。这使攻击者可以解密发送和接收邮件服务器之间的通信。
需要更安全的邮件传输
据知名网络黑客安全专家，东方联盟创始人郭盛华的研究和事件表明，这些攻击不是理论上的，而是在日常实践中发生的，从而导致信息泄漏。我们需要一种更安全的邮件传输方法，以抵消攻击者推迟和/或篡改邮件传输的企图。这是DANE for SMTP出现的地方。
DANE for SMTP（RFC 7672）使用DNS TLSA资源记录的存在来安全地发出TLS支持信号，并发布发送邮件服务器可以成功验证合法接收邮件服务器的方式。这使安全连接可以抵抗降级和MITM攻击。
可以使用DANE减轻先前描述的带有机会性TLS的SMTP的风险。如图4所示，该图显示了使用DANE进行邮件传输。
图4-此图显示了接收域的邮件服务器的DNS TLSA记录的存在被发送邮件服务器解释为使用TLS的功能。因此，在与接收域的邮件服务器进行通信时，可以强制使用TLS。TLSA记录中嵌入的指纹可用于验证接收邮件服务器的证书。因此，在发送方进行DANE验证的情况下，具有已发布TLSA记录的接收服务器不再容易受到上述MITM攻击。
使用DANE时，最好的做法是在证书未通过验证时，发送邮件服务器中止连接并尝试另一台服务器或推迟发送消息。
对于那些想将MTA-STS替代DANE的人来说：这种相对较新的方法似乎最适合大型云邮件提供商，没有像DANE那样被广泛采用，并且由于“首先信任” 而被认为不如DANE安全。使用和缓存，这在RFC 8461中得到了认可。但是，您可以在DANE旁边使用它，因为两个标准可以有意地彼此并存。
实施DANE的提示和技巧
如果您打算实施DANE，请参考以下提示和技巧。
入门
首先在您的MX域上发布DANE记录，或要求您的邮件提供商这样做。
下一步是在您的发送邮件服务器上启用DANE验证（或要求您的提供商/供应商启用或实现它）。我们的方法可能对这些步骤有用。
注意：DANE向后兼容。因此，如果您的邮件服务器支持DANE而连接的邮件服务器尚不支持DANE，则通常仍将使用STARTTLS或纯文本。
发布DANE记录
- DANE打算在MX域上发布。因此，如果您使用的是另一个域的邮件服务器，请确保通过设置一个或多个TLSA记录来要求该域的管理员支持DANE。
- 要注意的另一件事是DANE依赖于DNSSEC提供的安全性。在实施DANE之前，使您的主域和MX域支持DNSSEC。
- 注意：DNSSEC工具已经非常成熟并且可以完全自动化。此外，DNSSEC得到许多DNS提供商的支持，包括一些较大的参与者。
- 由于邮件服务器默认情况下不验证证书，因此为邮件服务器购买昂贵的证书对机密性没有增值或几乎没有增值。
- 建议使用证书的公共密钥来生成TLSA签名（选择器类型为“ 1”），而不要使用完整的证书（选择器类型为“ 0”），因为这样可以重复使用密钥材料。尽管偶尔刷新一下密钥材料是明智的，但是请注意，使用“向前保密”可以减少每次使用新密钥对的需要。
- 仅当接收邮件服务器提供完整的证书链时，颁发者证书（使用类型'2'）才有效。
- 确保TLSA记录的生存时间（TTL）不太高。这样可以在出现问题时相对快速地应用更改。建议在30分钟（1,800秒）和1小时（3,600秒）之间使用TTL。
- TLSA记录标识证书。如果证书被新证书替换，则相关的TLSA记录也需要及时更新。否则会出现不匹配，验证将失败，并且DANE感知的服务器不会将消息发送到接收者的域。DANE允许您发布多个TLSA记录来解决此问题。通过使用多个TLSA记录，您可以创建过渡方案。
- 实施对DANE记录有效性的监控。
验证DANE记录
- 越来越多的邮件服务器软件（如Postfix，Exim，Cloudmark，Halon，Cisco和PowerMTA）支持DANE验证。如果您使用的是此类软件，则可以启用DANE验证。
- 确保注意发送邮件服务器的日志，以查看哪些域未通过DANE验证。
- 某些软件允许测试模式。这意味着DANE验证已完成并记录下来，但如果DANE验证失败，则没有交付的后果。
欢迎转载分享