停止使用RSA密钥交换
“最安全的对策就是放弃RSA密钥交换并且转向（椭圆曲线）Diffie-Hellman…”
今天我们将论述应该停止使用RSA密钥交换的原因。SSL/TLS生态系统的一个最大弱点就是其向后兼容性。在其余互联网向前发展的同时，一些“恋旧”的落伍者可能将整个互联网至于危险的境地。就在上周，六位研究者发表了一篇论文，旨在详细论述一种古老漏洞利用攻击程序的新变体Bleichenbacher’s CAT，这种新变体就是抓住了上述提到的那个弱点。
那么，我们先花点时间解读这篇论文，主要看看它的涵义然后我们再论述不应该进行RSA密钥交换的原因。
让我们具体看看这篇论文。
谁是Bleichenbacher以及为什么我们应该注意Bleichenbacher’s CAT？
首先解读Daniel Bleichenbacher其人，他是一位瑞士密码学家，他的名字与几种漏洞利用攻击程序紧紧相连。通常来讲，这就意味着他是SSL/TLS最大的敌人之一。但是，他所做的是为了数据安全，并且他把这些程序用在了好的方面，也正因为这样，如今他很知名，至少达到了一个密码学家可能达到的知名程度。
在1998年，时年24岁的Bleichenbacher论证了一种生命力极强的对抗RSA加密执行的攻击手段。这种攻击手段使用了PKCS#1 v1.5编码功能。19年后，ROBOT（全称为the Return of Bleichenbacher’s Oracle Threat）在其原型上稍作变化就会威胁网站的TLS执行。
这两种漏洞利用攻击程序（加上两者间的修改）瞄准了RSA密码系统。于是，1998年网络攻击爆发，只是此后RSA依旧被广泛使用。然后，到了2017年，警报已赫然在目：停止使用RSA密钥交换。
并且，如果你需要更多的理由，那么如今又新公布了一种漏洞利用攻击程序Bleichenbacher’s CAT，可以把它理解为针对TLS执行阶段的Bleichenbacher内存攻击。这种攻击程序也是秉承了同样的攻击理念并进一步瓦解了RSA的防线。甚至Adi Shamir（RSA的创造者之一）也在论文中阐明了观点，也认为应该停止利用RSA密钥交换。
更多有关Bleichenbacher’s CAT的信息
Bleichenbacher’s CAT是一种由Daniel Bleichenbacher发布的基于原始漏洞利用攻击程序的变体。
虽然，一旦发现了新的漏洞利用攻击程序，就马上会提出相关的问题并且对RSA进行修补，但是阻止这种漏洞利用攻击程序复发的万全之策依然是完全停止使用RSA密钥交换。
这个问题由PKCS #1 v1.5衍生而来，我们撰写了整篇文章来叙述编码和不同类型的SSL/TLS证书。并且我建议阅读这些文章。只是PKCS #1 v1.5的节略本是PKCS1，也就是公钥加密标准#1，也正是PKCS1为RSA密码系统提供的定义和建议。
事实上，1.5版本已经过时，我们现在已在使用2.2版本；但不幸的是，还有一小部分网站仍在SSL/TLS上使用PKCS #1 v1.5。这就是为什么Bleichenbacher攻击会死灰复燃。在你使用1.5版本的RSA进行加密时，在加密之前有个填充阶段。填充值会随后被转换成整数并被因数分解。RSA密码系统就是基于两个大质数乘积的因数分解结果。问题在于，有相当数量的明文会被忽略掉，因此填充阶段就给加密带来了许多困难。
我们不会在加密的数学方面讨论太多，只要足够支撑当前论述的主题就好。接下来我们进行一些理论解释，然后我会把它运用到SSL/TLS上。
比起加密，解密更消耗计算资源。因为这个原因，许多公司将它们的SSL/TLS职能抛给了均衡负载以及其他边缘设备。我们讨论的是在服务端协商连接的数千个请求，而客户端最多只能同时协商几个连接。
因此，为了避免浪费过多的资源去解密无用的请求，使用一种被称为Oracle的东西来决定发送来的请求是否应该被解密。要说明一点，这里提出的Oracle并不是某知名公司的名称，而是RSA加密语境下的RSA工具。
Oracle根据填充做出决定。如果信息有正确数量的填充，Oracle将标记进行解密，若非如此，Oracle将忽略它。又或者，在一些情况下，回复失败信息。
Bleichenbacher漏洞利用攻击程序最让人瞩目的就是用来猜测填充的方法。这种方法随后就可以用来猜测密钥。更通俗易懂地讲，就是这种猜测不会用到SSL/TLS上。
对比Bleichenbacher’s CAT与SSL/TLS
让我们在交换过程中看Bleichenbacher’s CAT。在建立一个安全的连接之前，客户端和服务器端将进行TLS握手。这是一系列的步骤，通过这些步骤，客户端授权服务器端证书，协商密码组并在连接中使用，随后交换连接本身将使用的对称会话密钥。
再次重申，大规模地同时进行数万个握手，需要将这些功能全部卸载。但是，为了帮助缓解一些垃圾请求造成的系统负担，Oracle将决定一个消息是否会被解密。
这个漏洞利用攻击程序发生于密钥交换阶段。这个预备主密钥会被用来计算即将用在连接阶段的会话密钥。正如我们讨论的，如果使用通过PKCS1 v1.5定义的RSA，当把一个较小的预备主密钥（也许是128字节或者256字节）放入大公钥时，它就是用来填充弥补大小上的差距。
问题就发生在填充上，因为有一个“不能忽略”的可能性，也就是说利用随机字节序列向Oracle进行轰炸，这样最终就会成功发送一个看起来已经填充得很完整的信息。
大多数时候，服务器都会回复一个信息，告知客户端，信息并未被解密，因为信息并未被正确填充。
然而，如果正确的序列被猜到了，服务器就会发送一条不同的信息。如果一切进行顺利，Oracle就会促使服务器端解密预备主密钥，服务器端就会推断对称密钥并随后回复完成信息。
但是在这种情况下，因为攻击者可以猜测到填充但是没有发送正确的预备主密钥，因此完成的信息不会被正确加密。
这正合攻击者心意，因为这就开始缩小了预备主密钥的可能值范围。并且，一旦预备主密钥的值被猜到，密钥也就被猜到了。
起初，这种漏洞利用攻击程序是想通过RSA添加额外的安全机制来筛选，比如限制允许的请求数量或者在信息失败后不发送回复信息。然而，漏洞利用攻击程序在2003年进行了改进，随后又在2012年和2014年，它成为了DROWN攻击的重要组件，同时也是2017年ROBOT攻击的重要组件。从这一点上可以看出，它是已知的对SSL/TLS以及PKI最多变的威胁。
停止使用RSA密钥交换
当某个密码系统的创始者告诉你停止使用这个密码系统的时候，一定有其充分的理由。而在这个报告里也提到了：
支持一小部分[RSA]使用者将给所有人带来风险，因为这会让攻击者通过指定RSA作为服务器端唯一支持的公钥算法进行降级攻击。所以，这是向后兼容性具有危险的原因。
大多数的企业和组织都尽其所能地保持SSL/TLS至少在最新版本。要想完全告别TLS1.0其实还需时日，但是其实早就应该那么做了。整体来说，大方向还是正确的。
TLS1.3通过放弃支持RSA密钥交换（它也改进了上文提到的握手过程）完全解决了这个问题。不幸的是，只要还有一小部分客户端和服务器端使用RSA，这一切就毫无实际意义。如果你正好还在使用RSA，建议你放弃对RSA的支持并转向Diffie-Helman 椭圆曲线进行密钥交换。
现在，我要提醒大家，这虽然是一个生命力极强的漏洞利用攻击程序，但并不容易达成其攻击目的。所以，我们也不会很快就看到一系列Oracle填充攻击进攻互联网。
要想成功完成一次Bleichenbacher’s CAT攻击（这名字还真是拗口），你需要从其他虚拟机发送信息，并且把服务器端当作目标，而且这个虚拟机必须运行着与服务器端相同的操作系统。用一个远程外壳是行不通的。你还需要一定级别的许可来执行这次攻击，这需要服务器端的妥协才能达成。哦，对了，你还得避开杀毒软件才行。