从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，如果有人蛋疼去实现一下了？

 

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

 

摘自 心路