Easter Hack：SSL / TLS实现中的更多关键错误
自从我上一篇博客文章以来已经有一段时间了-写作的时间很少。 但是今天，我很高兴Oracle发布了全新的April 关键补丁更新 ，修复了我们钟爱的Java中的37个漏洞（严重的是，不要开玩笑-Java只是一种很棒的语言！）。 话虽这么说，我和我的同事报告的所有漏洞（贷记给Juraj Somorovsky，Sebastian Schinzel，Erik Tews，Eugen Weiss，Tibor Jager和JörgSchwenk）和我已经修复，如果您是我，我强烈建议尽快进行修补。运行由JSSE驱动的服务器！ 由于补丁程序尚不可用/暂时不可用，因此目前忽略了存在易受攻击的固件的加密硬件的其他结果-修复程序准备就绪时，将详细说明。
为了使这篇博客文章尽可能短，我将跳过很多细节，分析和先决条件，您需要了解这些细节，分析和前提条件才能理解本文中提到的攻击。 如果您有兴趣，请使用本文末尾的链接以获取更详细的报告。
恢复固定攻击
您还记得1998年以来Bleichenbacher对SSL提出的聪明的百万美元攻击吗？ 人们认为它已解决了TLS 1.0 RFC中指定的以下对策：
“避免遭受此攻击的脆弱性的最佳方法是以与正确格式化的RSA块无法区别的方式对待错误格式化的消息。 因此，当服务器收到格式不正确的RSA块时，服务器应生成一个随机的48字节值并将其用作主密码。 因此，无论接收到的RSA块是否正确编码，服务器都将发挥相同的作用。” –
资料来源： RFC 2246
简而言之，建议服务器在处理接收到的加密的PreMasterSecret（结构冲突，解密错误等）过程中出现问题时，创建一个随机的PreMasterSecret。 服务器必须使用随机生成的PreMasterSecret继续握手，并使用该值执行所有后续计算。 当检查“完成”消息时，这将导致致命的警报（由于客户端和服务器端使用不同的**材料），但是它不允许攻击者区分有效与无效（PKCS＃1v1.5兼容和不兼容）密文。 从理论上讲，如果（正确）应用了此对策，则攻击者不会获得有关密文的其他信息。
你猜怎么了？ 该修复程序本身可能会引入问题：
- 在有效和无效情况下，不同代码分支导致的处理时间不同
- 如果我们可以在负责分支的代码中触发Excpetions，会发生什么情况？
- 如果我们可以触发不同的异常，那将如何影响定时行为？
首先让我们看一下第二种情况，因为这是最容易解释您是否熟悉Bleichenbacher攻击的一种情况：
在JSSE中利用PKCS＃1处理
com.sun.crypto.provider.TlsPrfGenerator中的编码错误（缺少数组长度检查和错误的解码）可用于在PKCS＃1处理期间强制ArrayIndexOutOfBoundsException。 TheException最终导致JSSE堆栈中的一般错误，该错误以INTERNAL_ERROR SSL / TLS警报消息的形式传达给客户端。
我们可以从中学到什么？ 仅当我们已经在PKCS＃1解码代码块内时才发送警报消息！ 借助此辅助信道，可以再次发起Bleichenbacher的攻击：INTERNAL_ERROR警报消息表明已识别出PKCS＃1结构，但其中包含错误-其他警报消息是由不同的处理分支引起的（针对此攻击的对策） 。
仅当PKCS＃1结构包含特定结构时，才会触发边信道。 该结构如下所示。 如果在任何红色标记的位置中都包含00字节，则旁通道将帮助我们识别这些密文。
我们测试了已复活的Bleichenbacher攻击，并能够取回解密的PreMasterSecret。 对于2048位**，这花费了大约5小时和460000次查询到目标服务器。 听起来好吗？ 没问题……使用最新的高性能攻击改编 （非常感谢Graham Steel提供的有益的讨论！）只用4096位RSA**就只产生了约73710个查询！ 这次JSSE被成功利用了一次。 但是，让我们看一个更复杂的场景。 完全没有明显的旁通道：-（也许我们可以使用第一种情况…
依赖于机密的处理分支通向定时侧通道
在针对先前攻击的JSSE的代码分析期间，关于随机PreMasterSecret生成（显而易见，是Bleichenbacher对策）的显眼性已经很明显： 仅当PKCS＃1解码期间出现问题时， 才会生成randomPreMasterSecret。 否则，不会生成随机字节（sun.security.ssl.Handshaker.calculateMasterSecret（…））。
问题是，生成随机的PreMasterSecret会花费多少时间？ 好吧，这取决于并且对这个问题没有明确的答案。 测量有效和无效密文的时间显示模糊的结果。 但是至少，具有不同处理时间的不同分支会引入定时侧信道的机会。 这就是为什么在我们的研究期间对OpenSSL进行独立修补的原因，以确保有效和无效密文均获得相同的处理时间。
现代软件设计的风险
简而言之，事实证明不是随机数生成引起了时序侧信道，而是创建和处理异常的概念。 就处理时间的消耗而言，抛出和捕获异常是一项非常昂贵的任务。 不幸的是，从开发人员的角度来看，负责PKCS＃1解码的Java代码（sun.security.rsa.RSAPadding.unpadV15（…））是出于最佳意图编写的。 如果在PKCS＃1解码期间发生错误，则会引发Exceptions。 时间测量显示，当遇到有效/无效的PKCS＃1结构时，服务器的响应时间存在显着差异。 这些差异甚至可以在具有大量流量和噪声的实时环境（大学网络）中进行测量。
同样，这有什么用？ 总是一样的-当知道密文到达PKCS＃1解码分支时，您知道它被识别为PKCS＃1，因此代表了对Bleichenbacher攻击的有用和有效的旁道。 在我们的实时设置中，对基于OpenJDK 1.6的服务器的攻击大约花费了19.5h和18600个oracle查询！
JSSE第二次被击中……。
OAEP进行救援
你们中有些人可能会说“切换到OAEP，您的所有问题都消失了……。”。 我部分同意。 OAEP确实可以解决很多安全问题 （但绝对不是全部！），但前提是正确实施 。 曼格告诉我们 ，以错误的方式实施OAEP可能会造成灾难性的后果。 在查看OAEP解码代码insun.security.rsa.RSAPadding时，发现该代码包含的行为类似于Manger所描述的有问题的行为。 如果SSL / TLS已经提供OAEP支持，这可能会导致另一条旁道。
这篇文章中提到的所有漏洞都是固定的，但其他漏洞也将继续存在……我们提交了一份研究论文，该论文将更深入地说明此处提到的漏洞以及未发布的漏洞，因此请继续关注-还有更多。
非常感谢我的研究员Juraj Somorovsky，Sebastian Schinzel，Erik Tews，Eugen Weiss，Tibor Jager和JörgSchwenk，如果没有每个人的特殊贡献，我们所有的发现都是不可能的。 需要一支技术娴熟的团队，才能将理论攻击付诸实践！
可以在我的博士学位论文中找到对此处列出的所有漏洞的更详细分析，以及有关SSL / TLS安全的更多信息： SSL / TLS研究20年：对Internet安全基础的分析 。