编者按：在SSL／TLS的协议设计中，除了CBC模式，RC4之外，近几年还发现了一些其他相关的漏洞。在K.Bhargavan团队的相关研究中，三次握手攻击，SLOTH攻击，降级弹性等都是有代表性的研究。同时，在发现漏洞的工程中，研究人员还通过利用自动状态机来发现漏洞，具有很强的影响力。

　　SSL/TLS的近年相关攻击研究综述（二）

　　三次握手攻击

　　三次握手攻击，利用的漏洞是协议的设计问题，主要是利用TLS协议的RSA／DH密钥交换缺陷和会话恢复的缺陷来绕过防护措施。作为TLS会话的核心，会话的主密钥产生是经过客户端驱动产生的。客户端会生成预主密钥和一个随机值发送给服务器，而服务器也会生成一个随机值发送给客户端，并且，预主密钥是加密传输的，根据客户端和服务器端的三个值生成主密钥。

　　三次握手攻击在实际进行的时候需要利用恶意网站进行中间人攻击。客户端把自己生成的预主密钥和随机值发送给恶意网站，而恶意网站作为正常的接受方，可以通过正常方式解密客户端的预主密钥。然后恶意网站再与目标服务器发送请求，建立新的连接，并使用从客户端接收到预主密钥和随机值，并把服务器端的随机值转发给客户端。当握手过程结束的时候，恶意网站就拥有了和客户端，服务器相同的主密钥，并分别和客户端，服务器建立了连接。但是由于两个连接使用的证书是不一样的，而且每个连接都拥有不同的verify_data值。这就需要利用会话恢复的机制来进行下一步的破解。在会话恢复的时候，不要求进行证书的验证，也没有身份的验证。而仅仅通过主密钥进行通讯双方的身份认证，从而导致在握手结束的时候，Finished消息将一致，verify_data相同。这时攻击者再发起重协商，利用客户端的证书伪造自己的身份，从而控制两边的连接，发送任意修改的数据内容。从而完成攻击。这个攻击攻破了所谓安全的TLS连接，警醒设计者对协议的重新设计思考。作者也提出一些比较可靠的解决方案，如禁用重协商，只启用ECDHE加密套件和对所有网站都要求验证客户端证书等，但是每种解决方案都有一定的适用范围。[1]

　　SLOTH攻击

　　对于MD5和SHA-1的碰撞，很多实践者认为，它们在这些协议中的使用仅依赖于第二前级映像，不受碰撞的影响。作者在[2]中则是系统的进行研究和揭示这个论点的薄弱，并在密钥交换协议上设计出一类新的基于哈希结构的有效的冲突查找算法的碰撞攻击。通过在TLS1.2客户端身份验证上进行演示攻击和几乎现实化的TLS1.1，IKEv2和SSH-2的降级攻击，迫使多个TLS库进行更新，禁用主流协议中的弱哈希函数。其中SLOTH（security losses from obsolete and truncated transcrip thashes）是攻击者迫使使用弱哈希算法，如客户端TLS1.2版本可以利用MD5进行降级攻击。在握手的初期，客户端将ClientHello数据包发生给服务器；数据包中声明了服务器可以使用的签名和加密算法。然而，攻击者可以截获该数据包，并且向客户端发送一个要求更改算法的数据包，迫使客户端接受。至此，攻击者就开始了冒充目标服务器的攻击过程。位于客户端和服务器端之间的攻击者通过发送ServerHello、Certificate和ServerKeyExchange数据包响应客户端请求。在Server Key Exchange中，攻击者使用RSA-MD5算法替换客户端实际指定的算法。客户端接收到“服务器端”的响应，并最终使用弱哈希算法。随后，客户端再次发送Client Key Exchange响应，握手成功。TLS被降级后，中间人攻击者就可以冒充服务器，解密所有加密的流量。SLOTH也可以反向进行，导致服务器端被使用MD5降级攻击。针对这个攻击，最好的方案是在TLS1.2后的版本中删除MD5／SHA-1等弱哈希算法的支持，当然对于SSH和VPN也需要进行同样的更改。[3]

　　降级弹性

　　降级攻击是攻击者使用一些策略，让服务器和客户端采用比较弱的协议或者加密方式的一种攻击。类似于TLS，SSH，IPsec和ZRTP之类的密钥交换协议是高度可配置的，能够支持多种版本的协议，加密算法和参数等。这也是为了让协议能够具有更好的应用范围，所具备的敏捷性。作者在[4]中设计了一个正式的框架来研究降级弹性及其与密钥交换协议的其他安全属性的关系。通过剖析和归类经典攻击和一些新型攻击，总结其中的原因，并调查现有的标准降级弹性的相关内容，然后将这些结果与降级安全性结合起来，分析几个协议实现的条件，最后设计一套降低安全性的模式，并解释如何使用它们来加强现有协议的安全性。

　　论文中再次提及到Agility，现代协议具有加密敏捷性，其提供了多种协议和密码模式的可配置选择，使得在两个对等体之间实际执行的密钥交换取决于嵌入在交换中的协商阶段。在确保实际的协议实现方面，敏捷性已被证明其重要性。不幸的是，对算法敏捷性的支持为降级攻击提供了机会，在这种攻击中，主动网络攻击者干扰协商，导致诚实的对等方完成密钥交换，尽管使用的方式比自己使用的模式弱。为了防止对特定协议模式的攻击，关闭导致其协商的配置也是必要的。作者对降级弹性的探讨依然是建立在miTLS上的，考虑Initiator和Responder，引入了一个降级保护谓词DP，它可以对成对的配置进行操作，并且确定了一组配置来降低弹性。还引入了一个函数Nego，将两个相反角色的配置映射到协议模式，在没有攻击者的情况下应该协商。而且如果从符合DP的配置开始的两个对等体只能协商Nego确定的模式，即使在有攻击者的情况下，协议也会降级安全。例如，对于TLS协议，Nego的具体实例可能会确定两个TLS对等体配置通常会导致TLS1.2与密码套件的协商，例如DHE-RSA-AES256-GCM-

　　SHA384，具有2048位DH模数。但是，如果服务器支持不安全模式，例如DHE-EXPORT密码套件，则对手可能会迫使其降级到此模式。这表明如果没有其他对策，TLS1.2将不符合的定义。另一方面，仅具有一种可能模式的协议显然是安全的。[4]作者也证实了TLS1.2版本协议并不是降级安全的，还描述了IKEv2和ZRTP的新的降级漏洞，并提出相应的配置方案来避免这些漏洞，最后还证明了SSHv2是降级安全的。

　　利用状态机检测漏洞

　　SSL／TLS协议的设计是非常复杂的，其中在一些RFC的定义并没有被很好的实现，或者说在实现过程中存在偏差，导致存在着一些致命的漏洞。近几年有很多研究人员对TLS的实现做了深入的研究，如OpenSSL，MatrixSSL等，发现了一些比较有意义的漏洞，如HeartBleed，FREAK等。在发现漏洞的工程中，研究人员开发了很多新的方式，其中利用自动状态机来发现漏洞的方式就具有很强的影响力。

　　在TLS实现中，还存在着很多细节的问题需要解决。在[5]中，作者研究TLS握手的可验证安全性。通过miTLS验证了许多协议版本，配置和密码套件的主流浏览器和服务器的互操作性，并为其提供了在应用层可证明的安全性。在TLS协议的实现中，必须处理各种版本协议和相关的扩展，认证模式和密钥交换的方法，而不同的组合在客户端和服务器端之间又形成了不同的消息序列。作者在[6]中设计复合状态机来解决不同协议模式之间的细节问题，通过系统测试一些流行的开源TLS，发现了多年来隐藏在这些库里面的几个关键性安全漏洞。自动状态机是第一个用C语言写的，进行过验证的TLS状态机综合实现，并且可以嵌入到Open SSL中进行使用。利用论文中的方法可以对密码协议库的核心组件进行形式化验证。

　　经过20年的演变，TLS具有很多版本，扩展和密码套件，而且其中一些已经不被使用或者已经被确认为不安全。但是，客户端和服务器端的实现要保证具有灵活性，互操作性，导致它们的部署中通常会支持不安全的密码套件。当然握手期间的TLS会话的特定参数会通过MAC来验证，确保不会被篡改，而且如果客户端或者服务器端仅支持安全协议版本，那不管对等方支持什么不安全的套件，也只能和安全方保持一致。而在具体的实现中，就TLS1.0～TLS1.2而言，有一些细节地方不能被忽视。首先，协议中消息顺序是精心设计的，从互操作性和安全性的角度是不能随意更改的，比如Server CCS消息就必须在Server Finished消息之前发生。其次，客户端和服务器端必须要能区分真正可选的消息，而不是简单的线性接收和发送，类似于区分Server New Session Ticket和当前密钥交换消息。然后，不能过早地计算会话参数和秘钥，客户端应该在接收到服务器的消息后才确认握手过程。还有一些版本的协议，如SSLv23，DTLS都存在一些细节问题，在SSLv3中，客户端可能根本不发送Client Certificate消息，而DTLS则允许服务器使用新的HelloVerifyRequest消息来响应Client Hello。在TLS库中，还实现了许多在网络上不常用的密码协议，如PSK，DHanon／ECD Hanon，DHEPSK等，使用这些密钥套件时需要一些额外的协商参数。而对于重协商，在同一个连接上建立多个TLS握手，从逻辑上看，非常清晰，但是实现起来就相当棘手，也就导致了很多利用重协商漏洞的攻击。

　　作者利用[7]中开发的FLEXTLS工具来验证这些实现中的漏洞，该工具是建立在mi TLS上，经过验证的TLS实现。利用强大的消息传送和密码库，FLEXTLS能够用来评估协议的漏洞。使用该工具，发现最近的对TLS实现的攻击，如SKIP和FREAK，以及为FREAK和Logjam提供第一个验证演示。在[6]中，作者也应用了FLEXTLS工具来进行评估验证，测出很多细节漏洞。如Open SSL中Early CCS（CCS严格意义上不是hand shake message，不出现handshakelog中，不受客户端或服务器端状态机控制，可以出现在Server Hello后的任意位置，中间人通过在ServerHello之后向对方注入CCS消息，提前设置弱记录密钥，然后让他们完成握手，拦截合法的CCS消息），DH Certificate（client忽略Client Key Exchange，可能导致clientimpersonationattack），Server-GatedCrypto（SGC允许客户端收到serverhello后重新握手，但是表明某些extension是否被使用的信息会在新握手中消失），ExportRSA（512位弱签名），StaticDH（使用DHE或者ECDHE时，如果证书包含ECDH公钥，而且客户端不接受ServerKeyExchange，则会回滚到staticECDH，用服务器证书的公钥，导致前向安全性丢失）。还有JSSE相关问题，如Clientflaws（处理特定于某些密码的可选消息，客户端和服务器状态机都允许跳过消息，导致serverimpersonationattack），Serverflaws（JSSE服务器类似的允许客户端跳过消息）。还有一些关于NSS，Mono，CyaSSL和GnuTLS相关漏洞。这个状态机发现了很多实现过程中存在的漏洞，作者也对大部分漏洞进行了测试，验证漏洞的存在，并针对性的提出改进建议。

　　心脏出血

　　Heartbleed是OpenSSL实现上存在的漏洞，通过发送特殊信号Heartbeat给服务器，来查看服务器是否在线，当服务器在线时，会发送回复信息给主机，然后允许进行安全通信，服务器和主机会间断性的发送这个信号确保对方是否在线。心跳包设计之初是为了能够解决及时检测连接状态问题，相比TCP的keepAlive机制具有更大的灵活性，可以自己来控制检测的间隔和检测的方式。[8]

　　心脏出血漏洞最先是被谷歌安全中心的Neel Mehta提出来的，代码实现中没有对内容分配的限制，攻击者能够利用Heartbeat发送恶意信息给服务器，强制Open SSL服务器读取任意内存位置，攻击者还能够控制心跳的大小和结构，然后利用TCP协议，在443端口接收请求，一次可以收到64kb的服务器内存数据，多次请求，攻击者能够得到更多的服务器内存信息，有可能包括大量的邮件地址，密码等信息。OpenSSL从1.0.1版本到1.0.1f版本都广泛存在心脏出血漏洞，可想而知，数量巨大的服务器都会受到影响，根据Netcraft估计，17%的服务器都受到了影响，大约在50万台。

　　当然最致命的是攻击者可以用这种方式来获取加密密钥，泄漏的密钥允许攻击者解密过去和未来的相关流量，并且可以随意假冒服务。而且X.509证书中的加密和签名提供的保护都可以被绕过，那么从此泄漏中恢复需要修补漏洞，并撤销被泄漏的密钥，重新发布和重新分发新密钥。即使这样做，攻击者仍然可以解密过去拦截的流量，这些都必须由服务的业主来完成。

　　对该问题的解决最有效的方式是打补丁，可以选择升级OpenSSL版本，也可以配置OpenSSL协议来删除对心跳协议的支持。由于攻击者可能获取到密钥，所以最好替换私钥，并且要想保证过去的加密信息无法被泄漏的服务器私钥影响，可以部署具有前向保密性的加密方式。

　　Freak和Logjam

　　继Heartbleed后，OpenSSL又被公布了Freak（FactoringRSAExportKeys）漏洞，虽然这个漏洞的影响没有Heartbleed影响力那么大，但是很容易被中间人利用遭受中间人攻击。该漏洞源自于20世纪90年代，美国限制出口高强度的加密算法，限制加密强度最大为40位，密钥交换强度

　　最大为512位。从现在的计算速度来看，这中出口密码套件的安全强度是非常弱的，任何人都可以在几小时内完成破解。进行FREAK攻击，需要克服两个障碍，首先被注入的消息需要被目标服务器上的强RSA签名，然后为了修改TLS握手的消息，攻击者需要伪造Finished消息，使得对消息的修改变得合法化。完成这个中间人攻击：

　　1.在ClientHello中要求一个标准的RSA密码套件

　　2.MITM攻击者将服务器消息改为“exportRSA”

　　3.服务器使用512位exportRSA进行响应，并使用其长期密钥进行签名

　　4.根据OpenSSL的漏洞，客户端会接收这个弱键

　　5.攻击者对这个弱RSA进行破解，恢复RSA解密密钥

　　6.当客户端将发送预主密钥给服务器时，攻击者变可以解密它，恢复出TLS主密钥

　　7.攻击完成，可以注入任意内容实际上不仅仅是OpenSSL收到这个

　　攻击的影响，Android系统很多使用的OpenSSL库都存在了风险，而且随着攻击面的扩大，Apple的SSL／TLS（SecureTransport）和Microsoft的SSL/TLS库（Schannel）也收到了影响。对于Freak漏洞，只有建议各服务移除对出口密码套件的支持，因为这是这个攻击的必要条件。

　　在FREAK攻击之后，人们就把注意力集中到存在类似问题的Diffe-Hellman密钥交换算法上，把弱密钥交换机制进行移植，从而发布了新的漏洞Logjam。这个攻击复制了Freak攻击的原理，把RSA_export替换成DHE_export。和FREAK不同的是服务器要愿意使用不安全的DH参数，还需要缓存临时的DH密钥，最后还要求客户端能够愿意接受这些弱DH参数。所以最重要的原因就是浏览器能够接受不安全的DH参数。实际上，攻破1024位参数的攻击者能够对6.56%的HTTPS服务器进行被动攻击，攻破了10个通用组

　　的攻击者能够对约10%的服务器进行攻击。对于SSH，攻破一个标准组，能够使用被动攻击约360万的服务器，而IPsec则能攻击超过60%的服务器，影响力非常巨大。

　　缓解这个攻击其实也不难，首先禁用出口套件，然后升级DHE的套件，确保使用的是2048位而不是1024位，或者完全禁用DHE算法。

　　证书相关研究

　　SSL使用的证书是由CA签发的，基于可信的第三方来保证通讯的安全。在以前只有少数几个证书颁发机构的时候，可以通过保证自己的根证书的安全来保证颁发的证书的安全。但是，随着目前市场上的证书颁发机构增多，颁发的要求也参差不齐，导致有不少伪造的证书在被使用，严重威胁到了通讯安全。

　　近年来，有不少对检测伪造证书的研究。在[9]中，作者利用Flash Player的插件设计和应用了一套针对全球知名网站Facebook的SSL中间人攻击检测，分析了超过300万以上条实时的SSL连接，发现存在0.2%左右的SSL连接是使用的伪造证书。其中有大量的防毒软件，内容过滤器，也有一些是恶意软件使用的不合法证书。之前存在大量的商业证书机构都或多或少被欺骗发布过不合法的证书，这种情况下很多标准的浏览器也无法简单得区分出这些证书。但是更多的情况是用户忽略浏览器给出的警告信息，继续访问危险网站。有一些研究人员认为应该忽略掉证书过期的问题，他们表示证书过期是一件很常见的事情，如果经常给用户提示，会降低用户对警告的重视性。但是这样会导致一些伪造的过期证书被允许通过，也会带来严重的安全隐患。作者对收集到的伪造证书进行了特征分析，其中大部分的伪造证书非常小，通常没有超过1KB，只有很少部分超过5KB。而且伪造证书链比较短，链长大部分为一，通常是一些self-singed证书，极少含有中间证书。通过分析伪造证书的Subjects，发现大部分采用的是合法的域名，只有少部分使用的一些不相关的域名。其中大部分伪造证书都是选择好目标后，预先生成，而不是复制Facebook的合法证书。检查Issuers时，发现大量的伪造证书来源于防毒软件，防火墙，广告软件和恶意软件。实际上，在[10]中，作者分析了存在于TLS代理中的这些用于过滤TLS流量的防毒软件和父进程控制应用程序，并设计了一个集成框架来分析这样的客户端TLS代理。通过系统分析发现，其中一些工具严重影响其主机上的TLS安全性，还发现多个产品容易受到在中间人攻击的情况下完全服务器代理，并且如果启用TLS过滤，则还会更可能被攻击。其中的一些工具还误导浏览器，使其相信这样的TLS连接比实际更安全。通过检测发现，在实际的网络中，不安全的证书是确实存在的，而且存在的数量还不少。

　　网络中存在大量的伪造证书，导致受SSL保护的HTTPS看起来似乎也没那么安全了。证书安全是SSL协议安全的一个重要部分，而客户端正确验证服务器端发送的证书的有效性起着至关重要的作用。ChadBrubaker在[11]中提出了一种大规模测试证书在SSL实际应用中的有效性的方法。对真实证书片段增添一些限制和延展，利用“Frankencerts”合成不同的组合证书，并进行“差分测试”。也即在实际SSL应用中，发现一个证书被部分机构接收而被部分机构拒绝，就可以作为差异筛选条件，提取出来进行查询，用来发现其中存在的漏洞和不足。差分测试使用Frankencerts，涵盖了208个区别点，涉及的SSL应用包括OpenSSL，NSS，CyaSSL，GnuTLS，PolarSSL，MatrixSSL等。发现了在实际应用中存在着很多的问题，如MatrixSSL会接收X.509v1版本的证书，使得所有使用MatrixSSL的应用都能被中间人攻击。攻击者只需要一个有效的X.509v1证书就可以伪装成中间证书发布者，发布一些假的证书，并逃过MatrixSSL的检查。在GnuTLS中，也存在X.509v1证书的相关漏洞，由于两个标志的错误匹配，导致可以接收本地可信的X.509v1证书，即使是来自恶意服务器的证书。更严重的漏洞是来自于错检和漏检根证书对下层证书的限制。当然攻击能够实现的很重要的部分是用户忽略掉浏览器的提示，坚持访问不安全的网站，使得攻击者可以利用大量用户忽略证书过期的问题，伪造相应证书来完成中间人攻击。

　　X.509证书在实际应用中也存在不少的问题，验证证书的有效性涉及到解析ASN.1的数据结构并解释内容信息，过程比较复杂，也很容易出错。但是X.509证书被大量使用，从而具有不可替代性。为了应对X.509证书的一些结构和应用不足，Antoine提出了Cinderella[4]来改善X.509证书的使用。通过应用程序接收并验证证书完整性，有效性和一致性，取代之前的接收验证证书链的方式。这样省略证书产生更小的信息，隐藏证书内容具有更强的隐私性，嵌入一些额外的检测将具有更好的完整性。通过编写X.509模版来编写应用程序的新格式，使用Geppetto加密编译器为该策略生成零知识可验证计算方案。并为RSA-PKCS#1签名和ASN.1解析开发新的C库，提高加密可验证性能。在实际的应用中，对TLS支持细粒度验证策略，通过撤销检查和选择性披露证书内容，有效地将X.509证书转换为匿名证书。Cinderella利用可验证计算弥补了现有X.509基础设施和现代密码学之间的差距，并且能够使用户在较高级的应用程序中重用现有的证书链和签名机制，与现有的基础设施完美集成，不需要直接访问X.509签名密钥，使其与现有的基于硬件的解决方案兼容。Cinderella提高X.509身份验证和授权决策的灵活性，表达能力和隐私权，增加了“加密能力”。其中一个给定的验证策略可以将收集和验证最近的非撤销证据的责任移动到证书持有者，使验证者的撤销检查更简单和更高效，比较好的解决了CRLs和OCSP在线检查撤销状态的难题。

　　实际上，对于证书的有效性问题，研究人员提出了很多加强SSL安全的方法，如采用HTTP Strict Transport Security（HSTS）来遏制SSL剥离；使用The Public Key Pinning Extension for HTTP（HPKP）允许网站使用HTTP标头指定自己的公钥，并指示浏览器拒绝具有未知公钥的任何证书；使用TLS Origin-Bound Certificates（TLS-OBC）来封锁存在的很多中间人攻击插件；采用DNS-based Authentication of Named Entities（DANE），依赖与DNSSEC阻止伪造修改DNS记录来使使浏览器只接受一些特定的证书；Google提出并发布的证书透明性，可以实时检测伪造证书。有很多的想法和建议提出来解决证书问题，但是真正用于实践却比较难。AdamBates在[5]中提出了一些能及时解决目前存在的部分代码漏洞的方案，引入了对SSL实现的轻量级改进的CERTSHIM，以程序透明的方式来防止SSL漏洞，充当动态链接验证过程中的透明库。CERTSHIM具有良好的可扩展性，能融合Convergence，DANE和基于客户端的密钥固定等方法，并且只带来极少的延迟。利用CERTSHIM解决了部分遗留在数据库中的危险代码问题，也为后面的研究指明了方向，更是促进了证书验证的发展。

　　（作者单位为清华大学）

　　参考文献：

　　[1]K.Bhargavan，A.Delignat-Lavaud，C.Fournet.Triple Handshakes and CookieCutters：Breaking and Fixing Authentication over TLS.In IEEE Symposiumon Security and Privacy（Oakland），2014

　　[2]K.Bhargavan，G.Leurent.Transcript Collision Attacks：Breaking Authentication in TLS，IKE，and SSH.InNetwork and Distributed System Security Symposium（NDSS），2016

　　[3]B.Beurdouche，K.Bhargavan，A.Delignat-Lavaud.AMessyState of the Union：Taming the Composite State MachinesofTLS.InIEEE Symposiumon Security and Privacy（Oakland），2015

　　[4]K.Bhargavan，C.Brzuska，C.Fournet.Downgrade Resilience in Key-Exchange Protocols.In IEEE Symposiumon Security and Privacy（Oakland），2016

　　[5]K.Bhargavan，C.Fournet，M.Kohlweiss.Proving the TLS Handshake Secure（AsItIs）.InCRYPTO，2014

　　[6]B.Beurdouche，K.Bhargavan，A.Delignat-Lavaud.AMessy State of the Union：Taming the Composite State Machines of TLS.InIEEE Symposiumon Security and Privacy（Oakland），2015

　　[7]B.Beurdouche，A.Delignat-Lavaud，N.Koberssi.FLEXTLS：A Tool for Testing TLS Implementations.In USENIX Workshop on Offensive Technologies（WOOT），2015

　　[8]Z.Durumeric，J.Kasten，F.Li.Thematter of Heartbleed.InACM，2014

　　[9]H.Lin-Shung，A.Rice，E.Ellingsen.Analyzing forged SSL certificates in the wild.In IEEE Symposiumon Security and Privacy，2014

　　[10]X.CarneCarnavalet and M.Mannan.Killed by proxy：analyzing Client-end TL Sinterceptions of tware.InNDSS，2016

　　[11]C.Brubaker，S.Jana，B.Ray.UsingFrankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations.IEEE Symposiumon Security and Privacy，2014