作者：韦俊琳 清华大学
简介：SSL／TLS协议的设计是非常复杂的，其中在一些RFC的定义并没有被很好的实现，或者说在实现过程中存在偏差，导致存在着一些致命的漏洞。近几年有很多研究人员对TLS的实现做了深入的研究，如OpenSSL，MatrixSSL等，发现了一些比较有意义的漏洞，如HeartBleed，FREAK等。在发现漏洞的工程中，研究人员开发了很多新的方式，其中利用自动状态机来发现漏洞的方式就具有很强的影响力。
利用状态 机 检测漏洞 在TLS实现中，还存在着很多细节的问题需要解决。在[1]中，作者研究TLS握手的可验证安全性。通过mi TLS验证了许多协议版本，配置和密码套件的主流浏览器和服务器的互操作性，并为其提供了在应用层可证明的安全性。在TLS协议的实现中，必须处理各种版本协议和相关的扩展，认证模式和密钥交换的方法，而不同的组合在客户端和服务器端之间又形成了不同的消息序列。作者在[2]中设计复合状态机来解决不同协议模式之间的细节问题，通过系统测试一些流行的开源TLS，发现了多年来隐藏在这些库里面的几个关键性安全漏洞。自动状态机是第一个用C语言写的，进行过验证的TLS状态机综合实现，并且可以嵌入到OpenSSL中进行使用。利用论文中的方法可以对密码协议库的核心组件进行形式化验证。经过20年的演变，TLS具有很多版本，扩展和密码套件，而且其中的一些已经不被使用或者已经被确认为不安全。但是，客户端和服务器端的实现要保证具有灵活性，互操作性，导致它们的部署中通常会支持不安全的密码套件。当然握手期间的TLS会话的特定参数会通过MAC来验证，确保不会被篡改，而且如果客户端或者服务器端仅支持安全协议版本，那不管对等方支持什么不安全的套件，也只能和安全方保持一致。而在具体实现中，就TLS1.0～TLS1.2而言，有一些细节地方不能被忽视。首先，协议中消息顺序是精心设计的，从互操作性和安全性的角度是不能随意更改的，比如ServerCCS消息就必须在ServerFinished消息之前发生。其次，客户端和服务器端必须要能区分真正可选的消息，而不是简单的线性接收和发送，类似于区分ServerNewSessionTicket和当前密钥交换消息。然后，不能过早地计算会话参数和秘钥，客户端应该在接收到服务器的消息后才确认握手过程。还有一些版本的协议，如SSLv23，DTLS都存在一些细节问题，在SSLv3中，客户端可能根本不发送ClientCertificate消息，而DTLS则允许服务器使用新的HelloVerifyRequest消息来响应ClientHello。在TLS库中，还实现了许多在网络上不常用的密码协议，如PSK，DHanon／ECDHanon，DHE PSK等，使用这些密钥套件时需要一些额外的协商参数。而对于重协商，在同一个连接上建立多个TLS握手，从逻辑上看，非常清晰，但是实现起来就相当棘手，也就导致了很多利用重协商漏洞的攻击。
作者利用[3]中开发的FLEXTLS工具来验证这些实现中的漏洞，该工具是建立在miTLS上，经过验证的TLS实现。利用强大的消息传送和密码库，FLEXTLS能够用来评估协议的漏洞。使用该工具，发现最近的对TLS实现的攻击，如SKIP和FREAK，以及为FREAK和Logjam提供第一个验证演示。在[2]中，作者也应用了FLEXTLS工具来进行评估验证，测出很多细节漏洞。如OpenSSL中EarlyCCS(CCS严格意义上不是handshake message，不出现handshake log中，不受客户端或服务器端状态机控制，可以出现在ServerHello后的任意位置,中间人通过在ServerHello之后向对方注入CCS消息，提前设置弱记录密钥，然后让他们完成握手,拦截合法的CCS消息), DH Certificate(client忽略ClientKeyExchange，可能导致client impersonationattack), Server-Gated Crypto(SGC允许客户端收到serverhello后重新握手，但是表明某些extension是否被使用的信息会在新握手中消失), Export RSA(512位弱签名)，Static DH(使用DHE或者ECDHE时，如果证书包含ECDH公钥，而且客户端不接受ServerKeyExchange，则会回滚到static ECDH，用服务器证书的公钥，导致前向安全性丢失)。还有JSSE相关问题，如Client flaws(处理特定于某些密码的可选消息，客户端和服务器状态机都允许跳过消息，导致serverimpersonation attack), Server flaws(JSSE 服务器类似的允许客户端跳过消息)。还有一些关于NSS，Mono，CyaSSL和GnuTLS相关漏洞。这个状态机发现了很多实现过程中存在的漏洞，作者也对大部分漏洞进行了测试，验证漏洞的存在，并针对性的提出改进建议。 心 脏 出血 Heartbleed是OpenSSL实现上存在的漏洞，通过发送特殊信号Heartbeat 给服务器，来查看服务器是否在线，当服务器在线时，会发送回复信息给主机，然后允许进行安全通信，服务器和主机会间断性的发送这个信号确保对方是否在线。心跳包设计之初是为了能够解决及时检测连接状态问题，相比TCP的keepAlive机制具有更大的灵活性，可以自己来控制检测的间隔和检测的方式。[4]心脏出血漏洞最先是被谷歌安全中心的Neel Mehta提出来的，代码实现中没有对内容分配的限制，攻击者能够利用Heartbeat发送恶意信息给服务器，强制OpenSSL服务器读取任意内存位置，攻击者还能够控制心跳的大小和结构，然后利用TCP协议，在443端口接收请求，一次可以收到64kb的服务器内存数据，多次请求，攻击者能够得到更多的服务器内存信息，有可能包括大量的邮件地址，密码等信息。OpenSSL从1.0.1版本到1.0.1f版本都广泛存在心脏出血漏洞，可想而知，数量巨大的服务器都会受到影响，根据Netcraft估计，17%的服务器都受到了影响，大约在50万台。
当然最致命的是攻击者可以用这种方式来获取加密密钥，泄漏的密钥允许攻击者解密过去和未来的相关流量，并且可以随意假冒服务。而且X.509证书中的加密和签名提供的保护都可以被绕过，那么从此泄漏中恢复需要修补漏洞，并撤销被泄漏的密钥，重新发布和重新分发新密钥。即使这样做，攻击者仍然可以解密过去拦截的流量，这些都必须由服务的业主来完成。
对该问题的解决最有效的方式是打补丁，可以选择升级OpenSSL版本，也可以配置OpenSSL协议来删除对心跳协议的支持。由于攻击者可能获取到密钥，所以最好替换私钥，并且要想保证过去的加密信息无法被泄漏的服务器私钥影响，可以部署具有前向保密性的加密方式。
Freak 和 Logjam 继Heartbleed后，OpenSSL又被公布了Freak（Factoring RSAExportKeys）漏洞，虽然这个漏洞的影响没有Heartbleed影响力那么大，但是很容易被中间人利用遭受中间人攻击。该漏洞源自于20世纪90年代，美国限制出口高强度的加密算法，限制加密强度最大为40位，密钥交换强度最大为512位。从现在的计算速度来看，这中出口密码套件的安全强度是非常弱的，任何人都可以在几小时内完成破解。进行FREAK攻击，需要克服两个障碍，首先被注入的消息需要被目标服务器上的强RSA签名，然后为了修改TLS握手的消息，攻击者需要伪造Finished消息，使得对消息的修改变得合法化。完成这个中间人攻击[2]： 在ClientHello 中要求一个标准的RSA密码套件 MITM攻击者将服务器消息改为“export RSA” 服务器使用512位export RSA进行响应，并使用其长期密钥进行签名 根据OpenSSL 的漏洞，客户端会接收这个弱键 攻击者对这个弱RSA进行破解，恢复RSA解密密钥 当客户端将发送预主密钥给服务器时，攻击者变可以解密它，恢复出TLS主密钥 攻击完成，可以注入任意内容实际上不仅仅是OpenSSL收到这个攻击的影响，Android系统很多使用的OpenSSL库都存在了风险，而且随着攻击面的扩大，Apple的SSL／TLS（Secure Transport）和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/TLS协议设计是比较复杂的，在实现过程中很难全部参照RFC的标准，导致在实际应用中存在着很多的问题。随着近几年对TLS研究的深入，很多以前隐藏在实现中的问题，隐藏在库中的漏洞正在逐步被发现。通过不断的进行发掘，改进，升级，TLS也越来越能够被大众更加放心的使用。
参考文献： [ 1 ] K. Bhargavan, C. Fournet, M. Kohlweiss. Proving the TLS Handshake Secure (As It Is). In CRYPTO, 2014 [ 2 ] B. Beurdouche, K. Bhargavan, A. Delignat-Lavaud. A Messy State of the Union: Taming the Composite State Machines of TLS. In IEEE Symposium on Security and Privacy (Oakland), 2015 [ 3 ] B. Beurdouche, A. Delignat-Lavaud, N. Koberssi. FLEXTLS: A Tool for Testing TLS Implementations. In USENIX Workshop on Offensive Technologies (WOOT), 2015 [ 4 ] Z. Durumeric, J. Kasten, F. Li. The matter of Heartbleed. In ACM, 2014