我正在使用mailR通过R发送电子邮件。这是我的代码
send.mail(from = [from],
to = [to],
subject = "msg",
body = "contents",
html = FALSE,
inline = FALSE,
authenticate = TRUE,
smtp = list(host.name = "smtp.gmail.com",
port = 465,
user.name = [username],
passwd = [password],
ssl = TRUE),
attach.files = "/home/User/outputlog.txt",
send = TRUE)
我在附件中发送敏感信息。我正在通过SSL发送它。
我读了这篇文章，关于SSL的安全性，它看起来很安全。
此邮件在传输过程中是否加密？
理论上是的(对于"传输"的某些定义)，但在实践中，对于"此消息在传输过程中是否被加密？"答案是也许。简而言之，仅仅ssl = True或等效的东西放在某个地方几乎不能保证任何事情，原因如下所述。 因此，您可能不会喜欢以下详细回复，因为它基本上表明没有什么是简单的，即使您做对了所有事情并且您有很多事情要做，您也没有 100% 的保证。
此外，TLS 是您正在使用的功能的真实名称，SSL 自 20 天以来就已经死了，是的，每个人都使用旧名称，但这并不能使这种用法正确。
首先，也是非常重要的，TLS提供了各种保证，其中包括机密性(内容在传输过程中被加密)，但也包括身份验证，这在您的情况下更为重要，并且出于以下原因。
您需要确保正确解析smtp.gmail.com，否则如果您的服务器使用谎言解析器，并且位于重写 DNS 查询或响应的敌对网络中，那么您可以发送加密内容......到真正的"smtp.gmail.com"以外的另一方，这使得内容不再机密，因为您将其发送给陌生人或活跃的攻击者。
要解决这个问题，如果你是认真的，你基本上需要DNSSEC。 不，与许多人似乎相信和传达的相反，单独使用TLS甚至DOH - 基于HTTPS的DNS - 并不能解决这个问题。 为什么？因为以下不是纯粹的理论，因为它 最近(https://www.bleepingcomputer.com/news/security/hacker-hijacks-dns-server-of-myetherwallet-to-steal-160-000/)发生，即使它是在WWW世界中而不是电子邮件中，情况也可以相同：
- 您设法获取与联系人名称关联的 IP 地址(这可以通过 BGP 劫持来完成，并且由于配置错误、"策略"原因或主动攻击而一直发生)
- 现在您控制了所有通信，您可以将所需的任何服务器放在其末尾
- 您联系任何提供 DV 证书的 CA，包括纯自动化证书
- 由于该名称现在基本上解析为您控制的 IP，因此 CA 可以执行的 Web(甚至 DNS)验证将成功，CA 将为您提供此名称的证书(即使在 BGP 劫持结束后，该证书仍可能继续工作，因为 CA 可能不会快速吊销证书， 并且客户可能无法正确检查)。
- 因此，任何接受此 CA 的 TLS 堆栈都将很乐意接受此证书，并且您的客户端将使用TLS 安全地发送内容...到另一个目标而不是预期目标，因此 0 真正的安全性。
事实上，正如上面的链接所示，攻击者甚至不需要那么聪明：即使是自签名证书或主机名不匹配也可能通过，因为用户不会关心和/或库将有不正确的默认行为和/或使用库的程序员将无法正确使用它(请参阅这个迷人的，尽管现在有点旧了， 论文显示了许多"SSL"工具包的非常可悲的状态，这些工具包具有不正确的默认行为，令人困惑的API和各种错误，使得无效使用它的可能性远远超过正确的理智TLS操作：https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf)
正确使用 TLS 不会使 DNSSEC 变得无关紧要。两者都针对并防止不同的攻击。您需要两者都比仅使用一个更安全，并且两者中的任何一个(正确使用)都不会取代另一个。从来没有，也永远不会。
现在，即使分辨率正确，也可能有人劫持了(感谢BGP)IP地址。然后，再一次，您正在向某个主机发送一些加密内容，除了您没有真正验证谁是这个主机之外，因此如果攻击者设法劫持了smtp.gmail.com的 IP 地址，它可以是任何人(它不需要全局执行此操作，只需在本地，"围绕"您的代码执行)。
这就是身份验证非常重要的 TLS 属性发挥作用的地方。 这通常是通过 X.509 证书完成的(将在任何地方错误地称为 SSL 证书)。通信的每一端通过查看它提供的证书来验证另一端：要么将此证书识别为特殊证书，要么将此证书的颁发机构识别为受信任。
因此，您不仅需要在smtp.gmail.com上使用 TLS 进行连接，还需要仔细检查证书是否随后显示：
- 用于
smtp.gmail.com(而不是任何其他名称)，考虑到通配符 - 由您信任的证书颁发机构颁发
所有这些通常都由您使用的TLS库处理，但在许多情况下，您至少需要显式启用此行为(验证)，并且如果您想特别确定，则需要与您信任的CA明确决定。否则，会发生太多的攻击，就像过去流氓、无能或其他形容词 CA 所看到的那样，这些 CA 在不应该颁发证书的地方颁发证书(是的，没有人可以安全地防止这种情况，即使是 Google 和 Microsoft 过去也得到了错误颁发的证书，具有潜在的破坏性后果)。
现在您有另一个更特定于SMTP和SMTP的TLS问题：服务器通常通告它执行TLS，并且看到此消息的客户端可以启动TLS交换。然后一切都很好(排除以上所有内容)。 但是在SMTP服务器和您之间的路径中，有人可以重写第一部分(这是明确的)，以删除该SMTP服务器使用TLS的信息。然后客户端将看不到TLS，并将继续(取决于它的开发方式，当然在这种情况下是安全的，客户端应该中止通信)，然后清楚地说出来。这称为降级攻击。请参阅此详细说明，例如：https://elie.net/blog/understanding-how-tls-downgrade-attacks-prevent-email-encryption/
正如Steffen指出的那样，根据您正在使用的端口，上述SMTP STARTTLS问题不存在，因此不存在可能的降级，因为这适用于您未使用的端口25。但是，我更愿意仍然警告用户这种情况，因为它可能并不为人所知，降级攻击通常既难以检测又难以防御(所有这些都是因为现在使用的协议是在甚至不需要考虑防御路径上的恶意行为者的时候设计的)
然后，您当然会遇到您使用的TLS版本及其参数的问题。该标准现在是TLS版本1.3，但这仍然在各地缓慢部署。你会发现许多TLS服务器只知道1.2 如果采取一些预防措施，这可能足够好。但是你也会发现旧的东西说TLS 1.1,1.0甚至更糟(即SSL 3)。如果安全客户端代码无法保护至少 TLS 1.2 连接，则应拒绝继续交换数据包。 同样，这通常全部由您的"SSL"库处理，但您必须再次检查，启用正确的设置等。 您还有一个类似的降级攻击问题：如果不小心，服务器首先会以明文形式公布它提供的内容，因此攻击者可以修改它以删除"最高"的安全版本，以强制客户端使用具有更多攻击的较低版本(针对TLS 1.0和1.1的各种攻击)。 有一些解决方案，特别是在TLS 1.3和1.2(https://www.rfc-editor.org/rfc/rfc7633 中："TLS功能扩展的目的是防止降级 TLS 协议无法阻止的攻击。
撇开Steffen的观点相反，我不认为TLS降级攻击纯粹是理论上的。一些例子：
- (从 2014 年开始)：https://p16.praetorian.com/blog/man-in-the-middle-tls-ssl-protocol-downgrade-attack(主要是因为 Web 浏览器渴望无论如何都进行连接，因此通常如果具有最高设置的尝试失败，它们将回退到较低版本，直到找到发生连接的情况)
- https://www.rfc-editor.org/rfc/rfc7507 特别提供了保护，指出："所有不必要的协议降级都是不可取的(例如，从TLS降级 1.2 到 TLS 1.1，如果客户端和服务器实际上都支持 TLS 1.2);当结果是失去 TLS 扩展功能，通过降级到 SSL 3.0。 本文档 定义可用于防止意外协议的 SCSV 在符合本文档的客户端和服务器之间降级 通过让客户端指示当前连接尝试是 只是一个回退，如果服务器返回致命警报，如果 检测到不适当的回退。
- https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2019/february/downgrade-attack-on-tls-1.3-and-vulnerabilities-in-major-tls-libraries/讨论了2018年不少于5个允许TLS攻击的CVE："有两种方法可以攻击TLS 1.3。在每次攻击中，服务器也需要支持旧版本的协议。[..]第二个依赖于这样一个事实，即两个对等体都支持旧版本的TLS，密码套件支持RSA密钥交换"和"这种能力是由于TLS 1.3上唯一已知的降级攻击而实现的"和"除了协议降级之外，还存在其他技术来强制浏览器客户端回退到较旧的TLS版本： 网络故障、欺骗性的 TCP RST 数据包、缺乏响应等(参见 POODLE)"。
即使您使用的是正确的版本，也需要确保使用正确的算法、密钥大小等。有时某些服务器/库启用"NULL"加密算法，这意味着实际上没有加密。当然很愚蠢，但那是存在的，这是一个简单的案例，还有更复杂的案例。
Steffen的另一篇文章：https://serverfault.com/a/696502/396475 总结并触及了上述各点，并就什么是最重要的提出了另一种观点(我们不同意这一点，但他在这里也回答了这个问题，所以任何人都可以自由地考虑这两种观点并发表自己的意见)。
因此，MTA-STS而不是SMTP STARTTLS，https://www.rfc-editor.org/rfc/rfc8461 这个清晰的摘要：
SMTP MTA严格传输安全 (MTA-STS) 是一种机制 使邮件服务提供商 (SP) 能够声明其 接收传输层安全性 (TLS) 安全 SMTP 连接和 指定发送 SMTP 服务器是否应拒绝传递到 不提供具有受信任服务器证书的 TLS 的 MX 主机。
因此，您需要确保您发送电子邮件的主机也确实使用了该功能，并且您的客户端已正确编程以处理它。 同样，可能是在您的"SSL 库"中完成的，但这清楚地表明您需要在其中进行 SMTP 的特定位，并且您需要联系网络服务器以检索远程端 SMTP 策略，并且您还需要执行 DNS 请求，这在前面的一点上回到了您关于您是否信任解析器以及记录是否受 DNSSEC 保护。
综上所述，已经涵盖了许多领域并且确实很难正确完成，还有许多其他要点需要涵盖...... 让我们假设过境是安全的。但是，如何检索内容呢？你可能会说这不再是你的问题了。或。也许不是。你想为此负责吗？这意味着您可能还应该加密附件本身，这是对要保护的传输的补充(而不是替代)。 保护电子邮件内容的默认机制要么使用OpenPGP(具有更极客的触感)，要么使用S/MIME(具有更多的企业风格)。这适用于所有情况。然后，根据文档，您有特定的解决方案(但这并不能解决保护电子邮件正文的问题)，例如PDF文档可以通过密码进行保护(警告：过去已被破解)。
我正在发送敏感信息
然后，这可能会被一些合同或一些规范所涵盖，具体取决于您的业务领域。您可能希望更深入地研究这些要求，以确切地了解强加给您的要求是什么，以便如果您正确保护了其他所有内容，则无需对某些问题负责。
首先，即使在从客户端传递邮件时正确使用了SSL/TLS，它也只能保护传递的第一步，即传递到第一个MTA(邮件传输代理)。但是邮件通过多个 MTA 分多个步骤传递，然后最终从最后一个邮件服务器从客户端检索。
这些跃点中的每一个 (MTA) 都可以访问纯邮件，即 TLS 仅在跃点之间，而不是发件人和收件人之间的端到端。此外，初始客户端无法控制一个跃点将邮件传递到下一跃点的方式。这也可以通过TLS完成，但也可以以普通的方式完成。或者可以使用TLS来完成，其中没有证书得到正确检查，这意味着它对MITM攻击开放。除此之外，交付链中的每个MTA都可以访问纯文本形式的邮件。
除此之外，交付到初始MTA可能已经存在问题。当您将端口 465 与 smtps 一起使用时(TLS 从开始而不是使用 STARTTLS 命令从普通升级)，需要正确检查服务器的证书。我看了一下mailR的源代码来检查这是如何完成的：mailR本质上是使用来自Apache Commons的电子邮件。虽然 mailR 使用setSSL从一开始就启用 TLS，但它不使用setSSLCheckServerIdentity来正确检查证书。由于默认设置是没有正确检查证书，因此与初始MTA的连接容易受到中间人的攻击。
总之：由于邮件传递的工作方式(逐跳而不是端到端)以及mailR如何使用TLS，传递并不安全。为了拥有适当的端到端安全性，您将加密邮件本身，而不仅仅是传递。PGP和S/MIME是既定的方法。
有关详细信息，另请参见 SSL 在 SMTP 中的工作原理？和电子邮件环境现在的安全性如何？。