从RFC 5746的角度说Renegotiating的DOS攻击和MITM攻击

最近thc公布的SSL DOS漏洞挺火爆的,加上以前的那个MITM漏洞,估计各个公司都要忙一会儿。MITM漏洞我在《Renegotiating TLS Attack》中描述过,简单地说就是能够在任何使用低版本OPENSSL的系统中构造出一个CSRF攻击,以流量劫持为基础的无视WEB层防御的网络层 攻击,有点四维空间攻击三维“智子”的感觉。因为是TLS协议的问题,所以牛人们搞了一个扩展协议Renegotiation Indication Extension称之为secure renegotiation来解决这个问题。

这个新的RFC在TLS协议中增加了增加了三个状态和一个结构体,分别是secure_renegotiation标志位、 client_verify_data、server_verify_data以及renegotiation info结构体。secure_renegotiation标志位表示是否支持安全重新协商,client_verify_data表示客户端发送的上一 个TLS握手协商中最后一个包的尾部数据,TLS是12字节,SSL3是36字节。类似的,server_verify_data就是服务端发送的数据。 当第一次协商正在建立的时候renegotiation info中的renegotiated_connection被置为0。当客户端要求开始重新协商时,需要带上client_verify_data,类 似的服务器开始协商需要带上server_verify_data,这个数据对方会进行检验。当使用Renegotiating漏洞做MITM攻击时,攻 击者只是注入数据并不能解密数据,因此这个client_verify_data无法获得而导致失败。显然的,这个新协议彻底解决了 Renegotiating漏洞引起的MITM问题。openssl 0.9.8L使用关闭Renegotiating解决,后一个版本0.9.8M中重新启用了Renegotiating但是实现了secure renegotiation。需要注意的是,apache的mod_ssl配置中保留了一个兼容老客户端的选项 SSLInsecureRenegotiation,一旦设置为on就白升级了。

再说那个DOS漏洞,这个攻击方式的本质是消耗服务器的CPU资源,在协商加密算法的时候服务器CPU的开销是客户端的15倍左右。而 Renegotiating机制让攻击者可以在一个TCP连接中不停的快速重新协商,如果建立多个连接则服务端的压力更为可怕,而且这种攻击连接数很少导 致难以被察觉。THC宣告说即使关闭Renegotiating也不能避免攻击,是的,即使关闭了还是可以用类似connection flood的方式进行攻击,一个connection进行一次negotiating而不是Renegotiating。当然,这已经是一种缓解了,因为 这样的情况下攻击者的开销增大,服务端的连接数增多更容易监控到。也许有人会说,无需关闭Renegotiating只要升级了openssl、 apache之后似乎就解决问题了,但是这只是一种假象,因为目前流出的代码没有实现secure renegotiation,如果有人蛋疼去实现一下了?

其实目前的防御方案,都是拿着一个纸做的盾牌。

91ri.org注:文中所说的ssl DOS漏洞具体内容及工具本站已收录 大家可以通过 http://www.91ri.org/2429.html 查看

作者云舒 原地址:http://www.icylife.net/yunshu/show.php?id=821

本文由网络安全攻防研究室(www.91ri.org) 信息安全小组收集整理.转载本文请著名原文地址及原作者版权信息。