要理解这次攻击，我们必须回想一下 20 世纪后期 Bleichenbacher 的攻击。在该攻击中，攻击者使用目标服务器作为oracle。当使用基于 RSA 的密钥交换时，客户端应该使用PKCS#1发送一个使用服务器的公钥加密的秘密值（“预主密钥”）v1.5 填充（称为“类型 2”）。Bleichenbacher 的攻击依赖于发送精心设计的值来代替正确加密的消息，并观察服务器的反应。服务器可能（大部分时间）以错误消息响应“我处理了它，但它没有产生正确的 PKCS#1 v1.5 类型 2 填充”；但有时，解密似乎有效，服务器继续执行它获得的任何内容。攻击者看到了行为上的差异，因此获得了一点关于私钥的信息。在大约一百万个连接之后，攻击者知道的足够多，可以执行任意解密，从而破坏先前记录的会话。

这种攻击属于同一类型，但采用了一种依赖于 SSL 2.0 特性的新技术。SSL 2.0 是一个旧的协议版本，有几个严重的缺陷，不应该使用。它已被弃用超过 15 年。它甚至在 2011 年就被正式禁止。尽管如此，仍然有人支持 SSL 2.0。更糟糕的是，他们通过所谓的“导出”密码套件支持它，其中加密强度低至大约 40 位。

所以攻击有点像这样：

1. 攻击者观察到使用 RSA 密钥交换的加密 SSL/TLS 会话（一种现代的、强大的会话，例如 TLS 1.2），并且他想对其进行解密。并非所有 SSL/TLS 会话都可以受到上述攻击；攻击有效的概率约为 1/1000。因此，攻击者将需要收集大约一千个加密会话，并最终突破其中一个。作者认为，在一个看起来像 CRIME 和 BEAST（在后台触发不可见连接的恶意 Javascript）的设置中，这个集合可以自动化。

2. 服务器不小心将相同的 RSA 私钥用于 SSL 2.0 系统（可能是同一台服务器，也可能是另一个可能实现另一种协议的软件系统，例如邮件服务器）。攻击者有可能尝试与其他系统对话。

3. 攻击者开始与该系统进行 SSL 2.0 握手，使用ClientMasterKey从攻击者想要解密的值派生的值作为消息。他还要求使用 40 位导出密码套件。

4. 攻击者观察服务器的响应，并暴力破解服务器在解密攻击者发送的值时得出的 40 位值。此时，攻击者知道服务器使用其私钥处理其精心制作的值的部分结果。这间接地产生了一些攻击者真正感兴趣的加密消息信息。

5. 攻击者需要执行步骤 3 和 4 大约数千次，才能从目标会话中恢复加密的预主密钥。

有关数学细节，请阅读文章。

申请条件：

• 连接必须使用 RSA 密钥交换。如上所述，这种攻击对使用 DHE 或 ECDHE 密钥交换的连接（无论如何都推荐用于前向保密）的连接无能为力。

• 在实施 SSL 2.0 的系统中必须使用相同的私钥，攻击者可以访问，并且还接受协商“导出”密码套件。
  注意：如果使用 OpenSSL 且未针对 CVE-2015-3197 进行修补，即使“导出”密码套件被禁用，恶意客户端仍然可以与这些禁用的密码套件协商并完成握手。

• 攻击者必须能够与该 SSL 2.0 系统建立数千个左右的连接，然后为每个连接运行 40 位的暴力破解；总计算成本约为 2 ⁵⁰次操作。

必须很好地理解，2 ⁵⁰努力是针对攻击者试图解密的每个连接。比如说，如果他想从他观察到的连接中读取信用卡号，他将需要为每个信用卡号做大量的工作。虽然攻击非常严重，但在 CCN 抓取设置中并不实用。

解决方案：不要使用 SSL 2.0。该死。您应该在上个千年停止使用 SSL 2.0。当我们说“不要使用它，它很弱”时，我们是认真的。是时候醒来做你的工作了。

支持弱（“导出”）密码套件也不是明智之举。你猜怎么着 ？弱加密很弱。

停用 SSL 2.0 是解决此问题的唯一正确方法。当您使用它时，也请停用SSL 3.0。

（而且这种使用全大写首字母缩写词进行攻击的方式真的很荒谬。）

托马斯的回答很精彩。只有一件事似乎被低估了：电子邮件服务器在安全方面被破坏了......默认情况下和设计。

• 默认：例如，只需查看默认postfix配置（提示：SSLv240-56 位密码仍然是一回事，而且“无加密”也是如此）。

• 设计：你听说过StartSSL奇迹吗？SMTP嗯，这是唯一不被弃用的使用（“电子邮件”协议）实现加密的方法。奇妙的StartSSL是，当没有人在听时，它通常很强大，但如果有人想阅读......或者SSLv2如果有人想阅读HTTPS......

  ¯\_(ツ)_/¯

有关该领域中人们的心态和一些配置的示例，请参见那里。SMTP请注意，没有可以禁用的单个标志SSLv2（嗯，有一个，但如果服务器仍然接受并随后postfix响应，请不要感到惊讶）。SSLv2

这与问题有什么关系？

您可以随心所欲地加固您的 Web 服务器，如果您的SMTP服务器在有效证书上运行，那么您很可能容易受到相同的“DROWN”攻击。更糟糕的是，您的Web 服务器也会……通常情况下：您会惊讶于有多少SMTP服务器与服务器共享其证书HTTP。您还会对某些“独立”SMTP证书的有效域感到惊讶。

解决方案？

1. 正确配置您的SMTP服务器（并使用外部工具检查配置，例如sslyze）
2. 或者完全禁用SMTP。
3. 或者使用带有SMTP.