注意:请停止使用RSA密钥交换

0
827

 “最安全的对策是摒弃RSA密钥交换,转而使用(椭圆曲线)Diffie-Hellman加密算法……”

今天我们将讨论为什么应该停止使用RSA密钥交换。SSL/TLS生态系统最大的缺点之一是向后兼容性。当互联网中的其他人向前行进时,一些掉队的人可能会将整个互联网置于危险之中。上周,一个由六名研究人员组成的小组发表了一篇论文,详述了一种名为“Bleichenbacher’s CAT(Bleichenbacher的猫)的老把戏的新变种,从而突显出了这一弱点。

所以,让我们花点时间来阐释一下这篇论文,它的含义,然后我们会讨论为什么你绝对不应该使用RSA密钥交换。

让我们开始吧。

谁是Bleichenbacher,我为什么要关心他的猫?

让我们先来讨论一位名叫Daniel Bleichenbacher的瑞士密码学家。他的名字与几个漏洞有所重名,通常情况下,这会使他成为SSL/TLS最大的敌人之一,但这是网络安全,而且他一直在善用他的权力,所以现在他出名了。或者,至少和密码学家一样出名。

1998年,年仅24岁的Bleichenbacher演示了对使用PKCS#1 v1.5编码功能的RSA加密实现的可行性攻击。19年后,代表着Bleichenbacher的甲骨文威胁已经回归的ROBOT攻击,对最初的漏洞做了一些细微的改动,然后再次威胁到了网站的TLS实现。

这两个漏洞——以及它们之间的修改——都是针对RSA密码系统的,虽然1998年的攻击得到了解决,RSA继续被广泛使用,但到2017年,一切都已明确:停止使用RSA密钥交换。

如果你还需要更多的理由,现在我们有了Bleichenbacher’s CAT (Bleichenbacher对TLS实现的缓存攻击),这是一个新宣布的、利用了相同概念漏洞,它可以进一步破坏RSA。甚至它的创建者之一Adi Shamir——RSA中的S——也认为你应该停止使用RSA密钥交换。

请告诉我更多有关Bleichenbacher的猫的故事

Bleichenbacher的猫是Daniel Bleichenbacher所发布的初始漏洞的变种。

由于所有相关的漏洞都已经明确,有人便试图解决这个问题,并尝试修复RSA,但防止这个漏洞继续变异的唯一确定的方法是,完全停止使用RSA密钥交换。

这个问题源于PKCS #1 v1.5,我们之前写过有关的文章,但简要来说,PKCS1代表公钥加密标准#1,它为RSA加密系统提供了定义和建议。

1.5版本实际上已经过时了,我们现在使用的是2.2版本,不幸的是,少数网站仍在使用1.5版本用于SSL/TLS。这就是为什么Bleichenbacher攻击不断出现的原因。当你使用在1.5中定义的RSA加密某些东西时,在对数据进行加密之前,系统会对它进行填充。然后填充值会转换为整数并进行因数分解。RSA密码系统是基于两个大的质数乘积的因式分解,不幸的是,这一过程中需要避免一系列不安全的明文,因此便需要填充来加强加密。

我们不会过多讨论有关加密的数学问题,只要你能理解我所讲的内容。让我们从一个理论解释开始,然后再将其应用于SSL/TLS。

就计算资源而言,解密是一个比加密昂贵得多的过程——这正是许多企业将SSL/TLS功能卸载到负载平衡器和其他边缘设备的原因。我们讨论的是在服务器端协商连接的数千个请求,而客户端可能最多只能同时协商几个连接。

因此,为了避免将资源用于对解密没有帮助的请求,一些实现使用了名为Oracle的东西来确定是否应该解密传输的内容。值得注意的是,Bleichenbacher攻击中的Oracle并没有提到这家公司。它在RSA加密的上下文中提到了Oracle。

Oracle会基于填充结果做出决定。如果消息具有正确的填充量,Oracle数字解密就将产生结果,如果不具有,Oracle就会忽略它,或者在某些情况下,使用消息失败作为回应。

Bleichenbacher的漏洞真正代表的是一种猜测填充的方法,然后可以用它来猜测密钥。如果这看起来有些令人困惑,那么一旦我们将其应用于SSL/TLS,就不会了。

Bleichenbacher的CAT vs. SSL/TLS

在进行安全连接之前,客户端和服务器必须执行TLS握手。在这一过程中,客户端需要对服务器证书进行身份验证,协商将会在连接中使用到的密码套件,然后交换连接本身将会使用到的对称会话密钥。

同样,在规模上,有时同时进行数万次握手所需要的处理能力,可能需要完全卸载这些功能。但是,为了帮助消除一些垃圾请求,Oracle会决定是否需要解密消息。

此漏洞发生在密钥交换期间。预备主密码用于计算连接期间将会使用到的会话密钥。正如我们所讨论的,使用PKCS1 v1.5所定义的RSA,当把较小的预备主密钥(可能是128位或256位)放进大型公钥时,系统就会对它进行填充以弥补大小上的差异。

问题在于填充,过程中有一种“不可忽略”的可能性,即用随机序列的字节轰击Oracle时,最终你将发送一条看起来像是进行了正确填充的消息。

大多数情况下,服务器将返回一条消息,告诉客户端它不能解密该消息,因为它没有正确的填充。

但是,当对正确的序列进行猜测时,服务器将会发送一条不同的消息。如果一切顺利,Oracle就会允许服务器解密预备主密钥、推断出对称密钥,然后返回完成的消息。

但是在这种情况下,由于攻击者能够猜测填充,但是没有发送正确的预备主密钥,因此完成的消息不会得到正确的加密。

这正是攻击者想要的,因为它能够缩小预备主密钥值的范围。如果你能猜出那个值,你就能猜出密钥。

最初,这个漏洞是通过向RSA添加额外的安全措施来进行分类的,比如限制允许的请求数量,或者在消息失败时不发送响应。但是这个漏洞在2003年进行了改进,然后又在2012年和2014年进行了改进,之后,它便成为了DROWN攻击的一个关键组成部分,在2017年,它又成为了ROBOT攻击的一个关键组成部分——在这一点上,它是SSL/TLS和PKI所见过的最多产的威胁之一。

Bleichenbacher的猫找到了一种方法,可以通过向使用相同公钥的多个服务器发送查询来放大攻击。对于通配符SSL证书来说,这是一个比较常见的用例。事实上,这是部署通配符最大的缺点之一,即使用相同密钥的多个网站会增加受到攻击的几率。

停止使用RSA密钥交换

当给定密码系统的创建者告诉你停止使用它时,这通常是有充分理由的。这也是这个报告所提倡的:

“支持一小部分的[RSA]用户会让每个人都处于危险之中,因为它能够攻击者让执行降级攻击,方法是指定RSA为服务器所支持的唯一公钥算法。”

这就是向后兼容性如此危险的原因。

绝大多数企业和组织都尽力保持SSL/TLS实现至少在一定程度上是最新的。与TLS 1.0说再见所花的时间比它应该花的时间要长一些,但是总的来说事情正朝着正确的方向发展。

TLS 1.3完全解决了这个问题,因为它不支持RSA密钥交换。不幸的是,只要我们仍然需要支持一小部分客户端和服务器继续使用RSA,所有这些都是没有意义的。如果你属于这一类,建议你立即摒弃对RSA的支持,并切换到椭圆曲线Diffie-Helman来交换密钥。

现在,我要提醒大家。这一漏洞是可行的,但并不容易实现。因此,不要指望很快就会听到一系列Oracle填充攻击席卷网络。

为了执行Bleichenbacher’ CAT攻击(这并不是很容易脱口而出),你需要利用另一台运行在同一系统上的虚拟机来攻击服务器。你不能使用远程shell。你还需要一定的权限级别来执行攻击,而该权限级别又是你需要获取的。对了,你还需要避免被发现。

因此,我们可能不会看到这一攻击很快蔓延开来。

但是,就像最初的Bleichenbacher攻击一样,这一漏洞可能会继续改进,直到有一天,它成为了真正的威胁。

或者我们可以摒弃RSA。

LEAVE A REPLY

Please enter your comment!
Please enter your name here