Question

我正在使用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的安全性的文章，它看起来非常安全。

此消息在传输过程中是否得到加密？

Answer 1

理论上是（对于“传输”的某些定义），但是实际上是“在传输过程中此消息是否加密？”答案可能是。简而言之，出于以下说明的所有原因，仅将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浏览器无论如何都渴望连接，通常，如果使用最高设置的尝试失败，它们将回退到较低版本，直到找到发生连接的情况）< / li>
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/讨论了允许TLS攻击的2018年不少于5个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文档可以通过密码进行保护（警告：过去已被破解）。

我正在发送敏感信息

然后这可能会包含一些合同或某些规范，具体取决于您的业务领域。您可能想更深入地了解这些要求，以确切了解对您的要求是什么，以便在您正确确保所有其他内容的情况下对某些问题不承担责任。

Answer 2

首先，即使在从客户端传递邮件时正确使用SSL / TLS，它也仅保护传递的第一步，即，传递给第一个MTA（邮件传输代理）。但是，邮件通过多个MTA分多个步骤传递，然后最终从最后一个邮件服务器从客户端检索到。

每个跃点（MTA）都可以访问普通邮件，即TLS仅在跃点之间，而在发送方和接收方之间不是端到端的。另外，初始客户端无法控制一个跃点如何将邮件传递到下一跃点。 TLS也可以完成此操作，但是可以简单地完成。或者可以使用TLS来完成，在TLS中不会正确检查证书，这意味着它可以接受MITM攻击。除此之外，传递链中的每个MTA都可以访问纯文本邮件。

除了向初始MTA的交付可能已经存在问题之外。当您将端口465与smtps一起使用时（从TLS开始，而使用STARTTLS命令从普通端口升级），需要正确检查服务器的证书。我看过source code of mailR来检查它是如何完成的：mailR本质上是使用来自Apache Commons的电子邮件。并且，尽管mailR使用setSSL从启动启用TLS，但不使用setSSLCheckServerIdentity启用对证书的正确检查。由于the default is to not properly check the certificate 已经与初始MTA建立了联系，因此容易受到中间攻击的攻击。</ strong>。

总结：由于邮件传递的工作方式（逐跳而不是端到端）以及mailR如何使用TLS，传递是不安全的。为了拥有适当的端到端安全性，您将对邮件本身进行加密，而不仅仅是对邮件进行加密。 PGP和S / MIME是为此建立的方法。

有关更多信息，请参见How SSL works in SMTP?和How secure is e-mail landscape right now?。

SSL是否适合发送安全内容？

2 个答案: