SSL / TLS攻击的简要时间顺序

我已经很长一段时间没有担任过重要的职务了，所以现在该是发表一些有用和有趣的文章的时候了。 尽管不是特定于Java的，但对于某些人来说，这篇文章可能仍然很有趣。 阅读前的简短警告：这是篇很长的文章，但是-信不信由你-这只是一篇更长论文的简短摘要。 我将尽力使攻击描述尽可能简短-如果要详细介绍，请先对不起。 这篇文章仅作为SSL / TLS攻击的“简短”介绍。 如果您想了解更多信息，请看一下本文（您将在底部找到链接）。

那些不熟悉SSL / TLS（例如，如果您仅使用 SSL / TLS）的人可能需要对SSL / TLS的入门介绍。 对于快速而肮脏的介绍，您可能需要阅读Wikipedia上有关TLS的文章。 为了完整
详细了解您仍将需要努力克服RFC（ RFC 2246和RFC 5246应该足以清楚地了解正在发生的事情）。 每个类别的攻击按时间顺序排列：

对握手协议的攻击

1. 密码套件回滚

   Wagner和Schneier提出的密码套件回滚攻击旨在将客户端提供的密码套件列表限制为较弱的密码套件或NULL密码。 中间人（Mitm）攻击者可能会更改连接发起方发送的ClientHello消息，剥离不希望的密码套件，或者用弱者完全替换密码套件列表，然后将操纵的消息传递给所需的收件人。
   
   

2. ChangeCipherSpec消息投递

   Wagner和Schneier描述的这种简单而有效的攻击仅在SSL 2.0中可行。 在握手阶段，确定密码基元和算法。 为了激活新状态，双方都必须发送ChangeCipherSpec消息。 该消息通知另一方，以下通信将由先前商定的参数来保护。 收到ChangeCipherSpec消息后，立即激活挂起状态。
   位于Mitm的攻击者可能会简单地丢弃ChangeCipherSpec消息，并使双方永远不会激活待处理状态。
   
   

3. 密钥交换算法的困惑

   Wagner指出的另一个缺陷是Schneier，它与有关临时密钥材料的功能有关。 SSL 3.0支持在使用长期密钥签名的握手阶段（RSA公共密钥或DH公共参数）使用临时密钥材料。 问题是由于缺少传输材料的类型定义而引起的。 各方根据上下文隐式确定期望使用哪种密钥材料，并相应地进行解码。 更准确地说，没有有关已编码密钥材料类型的信息。 这为类型混淆攻击创建了一个表面。
   
   

4. 版本回滚

   Wagner和Schneier描述了一种攻击，其中将SSL 3.0的ClientHello消息修改为类似于SSL 2.0的ClientHello消息。 这将迫使服务器切换回更易受攻击的SSL 2.0。
   
   

5. Bleichenbacher攻击PKCS＃1

   1998年，Daniel Bleichenbacher提出了对基于RSA的SSL密码套件的攻击。 Bleichenbacher利用PKCS＃1 v1.5格式的严格结构，表明可以在合理的时间内解密PreMasterSecret。 基于RSA的密码套件中的PreMasterSecret是客户端生成的随机值，并在ClientKeyExchange中发送（加密和PKCS＃1格式化）。 窃听此（加密的）消息的攻击者可以稍后通过滥用服务器作为解密预言来对其进行解密。
   
   

6. 基于定时的攻击

   Brumley和Boneh概述了对基于RSA的SSL / TLS的定时攻击。 该攻击通过观察发送特制的ClientKeyExchange消息与接收到引发无效格式的PreMasterSecret的Alert消息之间的时间差异，从目标服务器提取私钥。 即使时间上的相对较小的差异也可以得出关于使用的RSA参数的结论。 Brumley和Boneh的攻击仅适用于基于RSA的密码套件。 此外，攻击还需要在攻击者的一侧安装高分辨率时钟。
   
   

7. Bleichenbacher进攻的改进

   研究人员Klíma，Pokorny和Rosa不仅提高了Bleichenbacher的进攻能力，而且还击败了对抗Bleichenbacher进攻的对策。
   打破对策防御Bleichenbacher攻击的对策是在任何类型的故障中生成一个随机的PreMasterSecret，并继续进行握手，直到由于不同的密钥材料而使Finished消息的验证和解密失败（PreMasterSecret在客户端和服务器端有所不同）。 另外，鼓励实现不发送可区分的错误消息。 此对策被视为最佳实践。 此外，由于在版本回滚攻击方面采取了不同的对策，因此加密数据不仅包括PreMasterSecret，还包括协商的SSL / TLS版本的主要和次要版本号。
   实现应检查发送和协商的协议版本是否相等。 但是在版本不匹配的情况下，某些实现会再次向发送方返回可区别的错误消息（例如，decode_error）。 显然，攻击者可以由此建立一个新的（恶意版本）oracle。 尽管存在建议的对策，但有了新的解密先知Klíma，Pokorny和Rosa才能够发动Bleichenbacher的攻击。 改善Bleichenbacher对PKCS＃1的攻击除了使Bleichenbacher攻击复活外，作者还可以改进算法以获得更好的性能。 这些优化包括重新定义可能的符合PKCS的明文的间隔边界。
   

8. 基于ECC的定时攻击

   Brumley和Tuveri对基于ECDSA的TLS连接提出了攻击。 该问题源自严格地实施用于改善标量乘法的算法，该算法是ECC严重依赖的，例如点乘法。 该算法可能被误用于提供时序侧信道，以显示有关所用乘法器的信息。
   
   

9. Bleichenbacher进攻的更多改进

   Bardou，Focardi，Kawamoto，Simionato，Steel和Tsay大大改善了Bleichenbacher的进攻能力，远远超出了以往的改进。 他们对算法进行了微调，以更快，更少的oracle查询执行。 此外，作者将他们的结果与以前的改进相结合，能够显着加快Bleichenbacher的算法。
   
   

10. 基于ECC的密钥交换算法混淆攻击

    Mavrogiannopoulos，Vercauteren，Velichkov和Preneel表明，密钥交换算法混淆攻击也可以应用于ECDH。 这组作者说，由于计算上的限制，他们的攻击尚不可行。 但是，正如在其他仅理论攻击中已经发现的那样，将攻击增强为切合实际或增加计算资源可能是时间问题。

对记录和应用数据协议的攻击

1. MAC不覆盖填充长度

   Wagner和Schneier指出，SSL 2.0包含与消息身份验证代码（MAC）有关的主要缺陷。 SSL 2.0应用的MAC仅覆盖数据和填充，但填充长度字段未加密。 这可能会导致消息完整性受损。
   
   

2. CBC使用的弱点

   Serge Vaudenay引入了一种新的攻击类别-填充攻击，并迫使安全界重新考虑加密方案中的填充使用情况.Vaudenay描述的攻击依赖于以下事实：块加密方案对固定长度的块进行操作，但实际上大多数明文必须填充以适合请求的长度（块长度的倍数）。 填充后，将输入数据传递到加密功能，在该功能中，将根据密码块链接模式（CBC）来处理每个（块大小长度的）纯文本块并将其链接起来。 CBC模式链接连续的块，因此后续块受其前任输出的影响。 这使得攻击者可以通过更改连续的块直接影响解密过程。

3. 通过压缩来泄漏信息

   凯尔西（Kelsey）描述了基于压缩的旁通道导致的信息泄漏。 这与作者所谓的“民间智慧”形成了鲜明的对比，后者认为应用压缩会导致增强安全性的系统。 凯尔西（Kelsey）表示，由于压缩会泄露明文中的信息，因此它几乎没有增加安全性，或者在最坏的情况下恰好相反;加密系统旨在加密明文，从而使所得密文几乎不泄露任何信息。在明文上。 凯尔西（Kelsey）观察到，通过使用压缩，出现了一个新的旁通道，可以用来获得明文提示。 因此，他将压缩的输出字节与输入字节相关联，并利用了压缩算法在应用于明文时减小输入数据大小的事实。
   
   

4. 拦截受保护的流量

   Canvel，Hiltgen，Vaudenay和Vuagnoux扩展了Vaudenay呈现的弱点，可以从SSL / TLS安全的IMAP会话中解密密码。 根据沃登尼的观察结果，提出了另外三种攻击类型：
   定时攻击作者得出结论，与无效填充引起的过早流产相比，成功进行MAC验证需要更多的时间。 该观察结果依赖于以下事实：执行填充检查比执行加密操作复杂，因为这是验证MAC所必需的。 多会话攻击这种攻击类型的基本思想要求在每个TLS会话中都存在关键的明文（例如密码），并且攻击者必须知道相应的密文。 由于安全最佳实践的性质，由于每个会话都会更改MAC和加密的密钥内容，因此相应的密文在每个会话中看起来都不同。 因此，检查给定的密文是否以特定的字节序列（在所有会话中都应相同）结尾是有利的，而不是尝试猜测整个明文。 字典攻击利用先前的攻击类型来检查明文的特定字节序列，该攻击旨在检查字典中包含的字节序列。
   

5. 选择明文攻击

   Gregory Bard和BodoMöller彼此独立地观察到一个有趣的细节，涉及SSL消息的初始化向量（IV）。 CBC模式下的每个加密和解密都取决于IV。 每个新的纯文本（由多个块组成）都应该拥有自己的，新鲜的和独立的IV。SSL的问题在于，根据SSL规范，只有第一个纯文本的IV是随机选择的。 所有后续的IV只是先前加密的明文的最后一个块，这与密码最佳实践完全相反。 Bard观察到，如果特定块具有特殊值并且拥有窃听密文，则愿意验证猜测的攻击者可以轻松地检查猜测。
   
   

6. 更多明文攻击

   他在2006年重新讨论了Bard提出的攻击。整个Bard都讨论了与以前相同的主题，但是提供了如何利用此问题的攻击概述。 Bard描述了一种情形，攻击者使用在受害者计算机上执行的Java小程序来发起上述攻击。
   
   

7. 流量分析

   乔治·丹内斯（George Danezis）在未出版的手稿中强调了攻击者如何利用明显的事实，即尽管连接受TLS保护，但最少的信息仍未加密以分析和跟踪流量。 尤其是Danezis使用TLS记录标题的每个TLS消息的一部分未加密字段进行分析.Danezis识别了这些未加密字段引入的一些信息泄漏：

   • 对不同URL的请求的长度可能不同，从而导致TLS记录的大小不同。
   • 对请求的响应大小也可能不同，这又导致生成不同大小的TLS记录。
   • 不同的结构化文档可能导致客户应用程序的可预测行为。 例如，浏览器通常会收集网站的所有图像，从而导致不同的请求和不同的响应。
   • 每个人都可以看到公共站点上的内容，攻击者可能会将内容（例如，按大小）链接到站​​点内容。

   此外，攻击者还可以通过提供特制的具有特定且可区分的内容长度，结构，URL或外部资源的文档，积极地影响受害者的行为，并获得有关其行为的信息（无需了解加密内容）。
   
   

8. IV链漏洞

   Rizzo和Duong提出了一种名为BEAST的工具，该工具能够解密HTTPS流量（例如cookie）。 作者实现并扩展了Bard，Möller和Dai的想法。 应用于块密码的CBC模式和可预测的IV的组合使得能够猜测明文块并验证其有效性。
   
   

9. 短消息冲突和破坏长度隐藏功能

   Paterson，Ristenpart和Shrimpton概述了与短消息结合的MAC-then-PAD-then-Encrypt方案相关的攻击。 特别是，如果消息的所有部分（消息，填充，MAC）都适合密码块大小的单个块，则它们的攻击适用。 在特殊的先决条件下，作者描述了创建多个密文导致相同的明文消息的情况。
   
   

10. 区分加密的消息

    Paterson等。 扩展了上述攻击，使攻击者可以区分两个消息。 作者概述了如何区分加密消息是否包含YES或NO 。 该攻击基于对窃听密文的巧妙修改，以使其通过处理或导致错误消息。 根据结果​​（错误/无错误），可以确定发送了哪些内容。
    
    

11. 破坏DTLS

    AlFardan和Paterson将Vaudenay的攻击应用于DTLS。 DTLS与常规TLS略有不同，适用于不可靠的传输协议（例如UDP）。 这些调整是有利的，同时也是不利的。 由于错误消息不会导致会话无效，因此Vaudenay的攻击可能适用于DTLS。 但是由于缺少错误消息，如果不进行调整，就无法使用Vaudenay引入的Oracle。 攻击者无法获得修改后的消息是否包含有效填充的反馈。 作者使用了由不一样的时间消耗的不同处理分支产生的时序预言来调整Vaudenay的算法。
    
    

12. 基于压缩的攻击

    2012年9月，Juliano Rizzo和Thai Duong提出了CRIME攻击工具。 CRIME的目标是HTTPS，并且能够解密流量，从而实现cookie窃取和会话接管。 它利用了由Kelsey在2002年发现的消息压缩引起的已知漏洞。

对PKI的攻击

1. 碰撞证书

   Lenstra，Wang和de Weger在2005年描述了攻击者如何通过计算MD5冲突来创建具有相等哈希值的两个有效证书。 使用冲突的哈希值可以模拟客户端或服务器，这种攻击很难检测到Mitm攻击。2008年，Sotirov等人证明了这种攻击的实用性。 通过合法CA的证书请求与大规模并行搜索MD5冲突之间的巧妙交互，他们能够为TLS创建有效的CA证书。 借助该证书，他们可以为任何域名颁发TLS服务器证书，而任何用户代理都可以接受该证书。
   
   

2. X.509约束检查弱点

   在2008年，Moxie Marlinspike发布了有关Microsoft Internet Explorer证书基本约束验证的漏洞报告。 Internet Explorer不会检查是否允许证书对子证书进行签名（从技术角度来讲，如果证书拥有CA：TRUE标志，则更是如此）。 由有效CA签名的任何有效证书都可以发布任何域的子证书。

3. 攻击证书颁发者应用程序逻辑

   Moxie Marlinspike演示了通过利用CA方面的实现性错误对PKI进行攻击的方法，他可以使用特制域字符串来欺骗CA的发行逻辑。 Marlinspike获得了由受信任的CA颁发的任意域的有效证书。
   
   

4. 直接攻击PKI

   Marlinspike描述了一种旨在干扰基础结构吊销证书的攻击。 通过使用联机证书状态协议（OCSP），客户端应用程序可以检查证书的吊销状态。 OCSP使用responseStatus响应查询。 响应结构包含一个主要的设计缺陷：并非所有字段都通过数字签名进行身份验证。充当Mitm的攻击者可以使用tryLater响应每个查询。 由于缺乏签名，客户没有机会检测到欺骗响应。 因此，受害者无法查询证书的吊销状态。
   
   

5. [更新]
   

   通配符证书验证

   弱点Moore和Ward发布了有关将IP地址用作X.509证书中的CN URI时通配符（*）使用的安全建议。 根据RFC 2818 ，IP地址不允许使用通配符。 作者发现，多个浏览器将包括通配符在内的IP地址作为证书CN视为有效并匹配。
   作者可能会欺骗浏览器以接受CN =” *。168.3.48”的已颁发证书。 该证书被视为对带有“ .168.3.48”后缀的任何服务器有效。 [/更新–感谢Richard Moore]

6. 拥有CA

   2011年3月15日，一个主要的证书颁发机构（CA）被成功破坏。 攻击者使用经销商帐户为受欢迎的域颁发了9个证书。
   
   

7. 欠下另一个CA

   发生上述攻击后不久，一个攻击者完全破坏了荷兰证书颁发机构。 与先前的攻击影响相比，攻击者能够控制CA的基础结构。
   
   

8. 攻击证书验证

   Georgiev等。 发现，SSL / TLS广泛使用的通用库遭受易受攻击的证书验证实现的困扰。 作者揭示了主要SSL / TLS库和基于这些产品或与这些产品一起构建的应用程序的源代码中的弱点。 作者检查了错误的根本原因，并能够利用大多数漏洞。 造成这些问题的主要原因是API规范不正确且具有误导性，对安全性问题缺乏兴趣（甚至
   银行应用程序！），并且缺少必要的验证例程
   确定。
   

各种攻击

1. 随机数的预测

   1996年1月，Goldberg和Wagner发表了一篇有关Netscape浏览器用于SSL连接的随机数质量的文章。 作者通过反编译获得了对应用程序源代码的访问权，并确定了负责随机数生成的算法中的显着弱点。
   
   

2. 有限的熵

   在2008年，Luciano Bello在代码审查期间观察到，由于实现错误，从2006年9月17日的0.9.8c-1版本到2008年5月13日的0.9.8c-4版本，可以预测Debian特定的OpenSSL的PRNG。 一个专用于Debian的补丁在libssl源代码中删除了两个非常重要的行，这些行负责提供足够的熵。
   
   

3. 基于异常的DoS

   赵等。 提供了对TLS握手的攻击，该攻击导致立即关闭连接，因此可用于拒绝服务（DoS）攻击。 作者利用先前讨论的两个弱点进行成功的攻击。

   • 第一个攻击针对TLS的Alert协议，并利用以下事实：由于在握手阶段仍缺少完整的加密原语协商，因此所有Alert消息均严格未经身份验证，因此是可欺骗的。 这可以发起明显但有效的攻击：欺骗致命警报消息，导致立即关闭连接
   • 第二次攻击只是通过发送来使通信伙伴感到困惑
     根据预期的握手流程，是误导或重播的消息，还是响应错误的消息

   
   

4. 重新协商缺陷

   Ray和Dispensa发现了由TLS的重新协商功能引起的严重缺陷。 该漏洞使攻击者可以在不破坏会话的情况下将数据注入到正在运行的连接中。 服务器会接受数据，认为其来源是客户端。 这可能导致滥用已建立的会话，例如，攻击者可能冒充当前登录到Web应用程序的合法受害者。
   
   

5. SSL / TLS剥离

   2009年2月，Moxie Marlinspike发布了sslstrip工具，该工具可在更高层禁用SSL / TLS。 作为前提条件，攻击者必须扮演Mitm。 要禁用安全层，该工具将发送HTTP 301 –永久重定向响应，并将所有出现的http s ：//替换为http：//（注意缺少s ）。 这将导致客户端移动到重定向页面并进行未经加密和未经身份验证的通信（当剥离成功并且客户端没有注意到她被欺骗时）。 最终，攻击者向（请求的）服务器打开一个新会话，并通过或更改任何客户端和服务器数据。
   
   

6. 计算DoS

   2011年，德国黑客组织黑客之选发布了名为THC-SSL-DoS的工具，该工具通过使用SSL / TLS握手请求压倒目标，从而在服务器上产生了巨大的负载。 通过建立新连接或使用重新协商来增加系统负载。 假设握手过程中的大部分计算是由服务器完成的，那么攻击会在服务器上比在自己的设备上创建更多的系统负载，从而导致DoS。 服务器被迫不断地重新计算随机数和密钥。

希望您能在这份详尽的漫长帖子后继续留在公司。 如果您知道对SSL / TLS的其他攻击，请告诉我！ 我将添加它们。

这篇文章是基于最近与JörgSchwenk一起发表的论文。 我们邀请所有对更多细节，攻击数字，对策和文献参考感兴趣的人阅读全文，其中提供了更多细节，并总结了每次攻击的“经验教训”。 如所承诺的，这是eprint论文的链接： 从以前的SSL / TLS攻击中学到的教训–攻击和弱点的简要时间表

参考：来自Java安全和相关主题博客的JCG合作伙伴 Christopher Meyer 简要介绍了SSL / TLS攻击的时间顺序 。

翻译自: https://www.javacodegeeks.com/2013/02/a-brief-chronology-of-ssltls-attacks.html