“最安全的对策是摒弃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。
