最近有一个新的“针对TLS”的攻击称为“ DROWN”。我了解它似乎使用了错误的SSLv2请求来恢复静态(证书)密钥。

我的问题是:如何? SSLv2?

奖励问题:如何阻止以服务器管理员身份发给我的攻击?首先如何产生攻击?

评论

发现的官方链接:drownattack.com包含有关此问题的全文,包括变体的详细信息以及可能受影响的计算机数量。

对五个字母的首字母缩写的痴迷使我感到困惑。

@DeerHunter TLA是如此近十年...

@DeerHunter公平地说,针对SSL的另一种攻击是POODLE,是6个字母:)

@MasonWheeler DETLA-双扩展三个字母的首字母缩写词(链接)

#1 楼

要了解这次袭击,必须回顾一下布雷申巴赫在20世纪后期的袭击。在该攻击中,攻击者将目标服务器用作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位。

因此,攻击的工作方式如下:
攻击者观察到使用RSA密钥交换的加密SSL / TLS会话(一种现代的,健壮的会话,例如TLS 1.2),并且他想对其解密。并非所有的SSL / TLS会话都可以接受上述攻击;攻击有效的概率约为1/1000。因此,攻击者将需要收集大约一千个加密会话,并最终突破其中之一。作者认为,在类似于CRIME和BEAST(在后台触发不可见连接的恶意Javascript)的设置中,此集合可以自动执行。
服务器不小心将相同的RSA私钥用于SSL 2.0系统(可能是同一服务器,可能是可以实现另一个协议的另一个软件系统,例如邮件服务器)。攻击者可以尝试与该其他系统进行通讯。
攻击者使用该系统开始的SSL 2.0握手,并使用ClientMasterKey消息作为源,该值源自攻击者想要解密的值。他还要求使用40位导出密码套件。那时,攻击者知道服务器使用其私钥处理其制作的值的部分结果。这间接产生了攻击者真正感兴趣的有关加密消息的信息。
攻击者需要执行大约几千次的第3步和第4步,才能从攻击者那里恢复加密的主密码。目标会话。

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

应用条件:


连接必须使用RSA密钥交换。如前所述,对于使用DHE或ECDHE密钥交换的连接(无论如何建议采用前向保密性),攻击无法起到很大作用。
在实施SSL 2.0的系统中必须使用相同的私钥,攻击者可以访问该私钥,并且该系统还接受接受以协商“导出”密码套件。注意:如果使用OpenSSL且未为CVE-2015-3197修补,如果禁用了“导出”密码套件,恶意客户端仍可以与那些禁用的密码套件进行协商并完成握手。
攻击者必须能够与该SSL 2.0系统建立数千个连接,然后每个都运行40位蛮力;总的计算成本约为250项操作。

众所周知,攻击者尝试解密的每个连接都要付出250努力。例如,如果他想从观察到的连接中读取信用卡号,则他将需要为每个信用卡号进行不可忽略的工作。虽然攻击非常严重,但在采用CCN进行抓取的设置中实际上并不实用。该死在上一个千年中,您应该已经停止使用SSL 2.0。当我们说“不使用它时,它很弱”,我们的意思是真的。现在该醒来做您的工作。

支持弱(“导出”)密码套件也不是明智之举。你猜怎么了 ?弱加密功能很弱。

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

(而且使用全大写首字母缩写词进行攻击的方式确实很可笑。)

评论


除了要回答问题的标题之外,我从来没有花任何时间来知道我会发现您在回答问题,社区,而且我也感激不尽,您是钻石。

–乌尔科马
16年1月1日在15:19

是的当我看到熊的答案时,我会投票赞成,然后开始阅读。感谢您所做的一切。这里的主持人不喜欢谢谢您的评论,但是在这种情况下,他们应该会有例外。

–void_in
16年1月1日在16:34

另请注意,在本文中的情况下,您可能会在单个CPU内核上进行大约1分钟的“特殊DROWN”攻击。

–́Riking
16年1月1日在18:12

我是否正确理解这需要双重缺陷:不仅提供SSL 2.0,而且在SSL 2.0和TLS 1.2连接之间重用相同的私钥?

– MSalters
16年1月1日在20:09

不确定我是否已经准备好就“ N世纪末”来谈论网络协议攻击。 ;-)

–loneboat
16-3-2在22:15



#2 楼

托马斯的答案很棒。似乎只有一件事被低估了:默认情况下和设计上,电子邮件服务器在安全性方面已被破坏。例如postfix的配置(提示:SSLv2和40-56bit密码仍然很重要,并且也“不加密”。)按设计:您听说过StartSSL感到好奇吗?好吧,这是使用SMTP(“电子邮件”协议)进行加密的唯一不建议使用的方法。 StartSSL的奇妙之处在于,它在没人听的情况下通常很强,但是如果有人想阅读...,或者如果有人想阅读SSLv2,可以很容易地将其默认设置为清除文本... br /> \\(_)_ /(


)那里有HTTPS领域的人的心态和一些配置的例子。请注意,没有一个标志可以禁用SMTP中的SSLv2(嗯,有一个标志,但是如果服务器随后仍然接受并响应postfix,请不要感到惊讶)。甚至与问题有什么关系?

您可以根据需要随意加固Web服务器,如果您有运行在有效证书上的SSLv2服务器,则很有可能容易受到攻击同样的“ DROWN”攻击。甚至更糟的是,您的Web服务器也会太...通常情况下:您会惊讶于有多少SMTP服务器与SMTP服务器共享证书。您还会对某些“独立” HTTP证书的有效性域感到惊讶。

解决方案?


正确配置SMTP服务器(并使用SMTP等外部工具检查配置)
或完全禁用sslyze
/>或将自签名/子域特定的证书与SMTP一起使用。


评论


1.恐怕不是解决方案。禁用弱加密会导致连接退回纯文本,这有什么意义呢? 2.是一种解决方案,假设您可以不使用电子邮件。 3.可能是现实的解决方案,实际上,许多MX服务器使用自签名证书。无论如何,CA给SMTP带来什么价值? RFC 7672为该主题提供了很好的讨论,并提供了一个长期解决方案:tools.ietf.org/html/rfc7672注意,问题在于MTA到MTA的连接,而不是MUA到MTA的提交。 (假设配置正确)

– Erwan Legrand
16-3-2在10:04



按“ 1”。我的意思是“仅对强密码使用“不建议使用的”纯TLS方案”。如果由于远程端无法与您的服务器通信而导致连接失败,那很可惜,但这就是安全性的代价(至少在您的端上,因为SMTP中没有端到端加密)。 3.我同意,但还不存在,“机会主义”通常等于“易受降级攻击”。 :)

–JPatta
16-3-2在11:26



另外,关于“ 1”。如果启用弱加密会导致连接容易受到这种攻击,那有什么意义呢?考虑到StartSSL几乎可以毫不费力地向任何活动的攻击者提供纯文本,并且可以像您正确地说的那样,在您的MTA和遥远的MTA之间拥有强大的加密功能并不能保证所有这些内容都比纯文本更糟。其余的MTA到MTA连接已加密。

–JPatta
16-3-2在11:37



我不认为StartTLS是“被设计破坏”的。是的,您可以通过MITM绕开它,但是客户端可以检测到。问题不是StartTLS,而是大多数SMTP客户端将接受不带TLS的连接-这是为了向后兼容。如果有的话,请怪SMTP本身。 SSMTP在其自己的端口上也存在相同的问题-您可以阻止该端口,客户端将在没有TLS的端口25上重试。

–sleske
16 Mar 2 '16 at 16:58

无论如何,如果您在邮件服务器上禁用SSLv2 / 3,则可以避免DROWN。不需要自签名证书(这会导致其他问题)。

–sleske
16-3-2在16:59