我正在使用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 is的安全性的文章，它看起来非常安全。
此消息在传输过程中会被加密吗？
最佳答案
理论上是（对于“传输”的某些定义），但是实际上是“在传输中此消息是否被加密？”。答案可能是。简而言之，出于以下说明的所有原因，仅将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可以进行的网络（甚至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在不应该颁发证书的情况下发生过这种攻击（是的，没有人可以抵御这种攻击，即使Google和Microsoft过去也曾使用错误的证书潜在的破坏性后果）。
现在，您还有另一个更特定于SMTP和TLS上SMTP的问题：服务器通常会通告它执行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版，但是它仍在缓慢地部署到任何地方。您会发现许多仅知道1.2的TLS服务器
如果采取一些预防措施，这可能就足够了。但是您还会发现旧版本的TLS 1.1、1.0甚至更糟（即SSL 3）。如果安全客户端代码无法确保至少TLS 1.2连接的安全，则应拒绝继续交换数据包。
同样，这通常都由“ SSL”库处理，但同样，您必须进行检查，启用正确的设置等。
您也有类似的降级攻击问题：服务器无意间首先就清楚地宣传了其提供的内容，因此，攻击者可以对其进行修改，以删除“最高”安全版本，以迫使客户端使用具有更高安全级别的较低版本。攻击（针对TLS 1.0和1.1的攻击有多种）。
有一些解决方案，特别是在TLS 1.3和1.2（https://tools.ietf.org/html/rfc7633中：“ TLS功能扩展的目的是防止降级
TLS协议无法阻止的攻击。”）
除了Steffen的观点外，我不认为TLS降级攻击纯粹是理论上的。一些例子：
（从2014年开始）：https://p16.praetorian.com/blog/man-in-the-middle-tls-ssl-protocol-downgrade-attack（主要是因为Web浏览器渴望连接，无论通常情况下，如果尝试使用最高设置失败，它们都将回退到较低版本，直到找到发生连接的情况）
https://tools.ietf.org/html/rfc7507特别提供了一种保护措施，指出：“所有不必要的协议降级都是不可取的（例如，来自TLS的降级）
如果客户端和服务器都确实支持，则从1.2到TLS 1.1
TLS 1.2）；当结果是失去
通过降级到SSL 3.0来实现TLS扩展功能。这个文件
定义可用于防止意外协议的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://tools.ietf.org/html/rfc8461具有以下清晰的摘要：
SMTP MTA严格传输安全性（MTA-STS）是一种机制
使邮件服务提供商（SP）声明其能力
接收传输层安全性（TLS）安全SMTP连接和
指定发送SMTP服务器是否应拒绝传递到
不提供带有受信任服务器证书的TLS的MX主机。
因此，您需要确保您发送电子邮件的主机也确实使用了该功能，并且您的客户端已正确编程以处理该功能。
再一次，可能是在“ SSL库”内部完成的，但这显然表明您需要在其中使用SMTP的特定位，并且您需要联系网络服务器以检索远程端SMTP策略，并且还需要执行DNS请求，然后返回关于您是否信任您的解析器以及记录是否受DNSSEC保护的较早的观点之一。
以上所有内容已经涵盖了许多领域并且确实很难正确完成，但仍有许多其他要点...
让我们假设运输是安全的。但是，如何获取内容呢？您可能会说这不再是您的问题。也许。也许不吧。您要为此承担责任吗？这意味着您可能还应该对附件本身进行加密，这是对传输进行了保护（而不是替代）。
确保电子邮件内容安全的默认机制是使用OpenPGP（对此有更多的怪异之处）或S / MIME（对它有更多的企业联系）。这适用于一切。然后，您将根据文档获得特定的解决方案（但这不能解决保护电子邮件正文的问题），例如PDF文档可以通过密码进行保护（警告：过去已被破解）。
我正在发送敏感信息
然后，这可能会包含一些合同或某些规范，具体取决于您的业务领域。您可能想更深入地了解这些要求，以确切了解对您的要求是什么，如果您正确地确保了所有其他内容，则对某些问题不承担责任。
关于r - SSL是否适合发送安全内容？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55821053/