带有 STARTTLS 的 SMTP本身并不是一个漏洞，尽管考虑到典型 TLS 实现的复杂性，它提供了更大的攻击面。如果您不需要它，请将其关闭（NIST SP800-123 §4.2.1 PDF）。

如果您仅依靠 SMTP+STARTTLS 进行保密通信，则很容易出错。

STARTTLS 协议（或多或少的LDAP、FTP 、 POP3 和 IMAP，甚至是Apache 支持的HTTP，尽管它从未流行起来）本质上从安全策略和防火墙的角度管理起来更棘手。例如，如果您有一条规则允许 HTTPS 连接到正确配置的 Web 服务器，那么防火墙所需要做的就是验证/强制执行 SSL/TLS 记录。

使用 STARTTLS 协议，为确保加密具有类似的置信度，您必须进行更强大的协议检查（可能在您的防火墙上不可用，可能需要代理）；或者对客户端和服务器实现有更大的信心（例如，防止发送或接受纯文本凭据）。

以上几点或多或少是关于警告的内容：使用像 HTTPS 这样的严格 TLS 协议，您可以比使用 STARTTLS 和可能的可选加密协商更有信心（除了 NULL 密码）连接加密。这是需要评估的风险，而不是漏洞。

典型的（非客户端身份验证）SMTP+STARTTLS 配置（根据我的经验）是：

• 机会性 STARTTLS
• 在错误或缺少 STARTTLS 时回退到明文
• 默认值很差（密码选择、证书验证）

要正确使用 STARTTLS 来提高通信安全性，您必须考虑 DNS、房间里的大象、MX 备份和 MX 覆盖（“mailertable”）。

带有 STARTTLS的客户端身份验证 ( SMTPAUTH ) 服务器更容易保护，如果它只是为了中继目的启用漫游客户端安全身份验证（通过客户端证书、用户名/密码或两者）。

理想的安全通道实现提供（至少）三件事：

1. 机密性/隐私（加密）
2. 真实性（一方或双方的身份证明）
3. 完整性（防篡改或防篡改）

SMTP+STARTTLS 与此不同：

• 由于通信重新开始并依赖于未经身份验证的、可破坏的纯文本通道，因此存在 MITM 干扰的范围。如果 STARTTLS 是机会主义的，这意味着它可能会被轻易颠覆（如果您曾经看到 Cisco PIX 或 ASA 执行其 SMTP 协议“修复”，您会看到类似的操作）。如果证书验证不严，也会出现类似问题。
• SMTP 是一种存储转发协议，TLS 能力只是点对点的，没有类似 HTTP 代理的“CONNECT”功能。即这不是端到端加密。机密性、身份验证和完整性仅限于连接，而不是消息，这可能不是用户期望或要求的。另请参阅非技术用户如何验证消息是否“安全”发送？...或通过 TLS？

这个想法是您应该默认启用 SSL 并且不允许纯文本通信。STARTTLS 意味着如果您愿意，您必须明确告诉服务器使用 SSL。

从技术上讲，是的，提供未加密的通道意味着信息可能会不安全地传输到您的服务器或从您的服务器传输。问题是并非所有邮件服务器都提供加密，如果您想从不支持加密的邮件服务器接收/发送邮件，您必须允许这样做。

这确实可能允许中间人假装每个端点不支持加密并在中间注入自己，但不幸的是，另一种选择是使大部分邮件传递失败。

在 STARTTLS 之前，初始握手发生在明文上，因此位于同一网络上的攻击者可以伪造服务器响应，并使用户觉得服务器无法进行 TLS 握手。这可能会导致缺陷。