Openssl renegotiation DoS attack is still an issue

Openssl renegotiate would causes DoS attack was disclosured in 2011，then THC released their DoS attack tools. This issue what we called CVE-2011-1473 until now the openssl upstream community doesn't give any solution.  So, it seems they've been leaving this issue to the application developers( suck this shit in mind), such as Apache2 provide a optional config that you can disable renegotiation.

Let's see what Apache2 server would do in most cases:

shawn@fortress / $ openssl s_client -connect build.opensuse.org:443

..............................

..............................

Timeout   : 300 (sec)  

Verify return code: 20 (unable to get local issuer certificate) ---

R   // Press R, then enter

RENEGOTIATING 140722018514592:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:592:


According to Vincent Bernat, a server will require 15 times the processing power of a client, which means an Intel i7 CPU laptop can kick a bunch of servers's ass. Plz take a look at my test data:

Test environment：SLES 11 SP2 , assigned 2 cores + 1GB memory in virtual machine

Case I:

Server: openssl s_server -key server-key.pem

Client: thc-ssl-dos 192.168.0.1 4433 --accept -l 10000

The worst case:

Cpu0 : 1.3%us, 1.7%sy, 0.0%ni, 97.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu1 : 53.1%us, 5.1%sy, 0.0%ni, 37.1%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st

Case II:  Vincent Bernat provided us an open source hardening/mitigation solution, which add some rate-limit/fixed hex data for filtering on the netfilter.

#sh iptables.sh

#iptables -A INPUT -d 192.168.0.1 -p tcp --dport 4433 -j LIMIT_RENEGOCIATION

Server: openssl s_server -key server-key.pem

Client: thc-ssl-dos 192.168.0.1 4433 --accept -l 10000

The worst case:

Cpu0 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu1 : 0.0%us, 0.7%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Well done, Vincent! Your solution works. But I'm not sure this may cause the side-effect. Vincent added some fixed hex data as filtering policy on the netfilter. What if the same hex data occurs? Is false positive possible?