Hi Tomas, Thanks for your reply!
>>> On 1/10/2012 at 08:12 PM, in message <20120110131229.7ede5...@redhat.com>, Tomas Hoger <tho...@redhat.com> wrote: > Hi Guanjun! > > On Sun, 11 Dec 2011 20:35:02 -0700 Guan Jun He wrote: > >> I have just produced a patch against the upstream HEAD version, to >> seek a way to fight against DoS attack in openssl itself, the logic >> is simple, get client's ip address in BIO layer, and send this info >> to upper SSL layer; In SSL layer, according to the client ip and >> control policy to do control. And I have just finished the >> enhancement to use rb-tree as the main struct, the patch is >> attached,and have took a simple test from 2 machines. > > It seems you're trying to address more than just CVE-2011-1473 via this > patch, which results in a fairly large patch. Why do you need to track > client IP at all? This issue is about client's ability to do unlimited > number of renegotiations within single connection. To limit that > (either to a maximum total, or rate limiting), you should not really > need to care about client's IP. If do not care about client's IP, then the rate limiting is aimless, that means all legitimate ssl requests will be blocked, and cause another 'DoS'. With client IP, then it can just block the specific(attacking) client ip, all other legitimate ssl requests can be processed normally. > You also seem to store IP as 32bit > value, which does not sound like it should work correctly for IPv6. That should be adjusted to support IPv6, and can be done. When I produce this patch, s_server and s_client still not support IPv6, so I didn't consider this. > > Your IP tracking probably helps limit total number of handshakes > (initial or renegotiation) from one IP over all connections. It may be > easier to limit handshakes in one connection and enforce connection > limit (max concurrent connections or connection rate) elsewhere, where > it can be done easily and where it's usually done - in firewall. Your > mails suggest that you're actually testing it by doing only initial > handshake over multiple connections, rather than using re-handshakes > within single connection. > > > On Mon, 19 Dec 2011 02:11:23 -0700 Guan Jun He wrote: > >> I have just tested and updated the patch,it works ok,and with a >> little performance loss(<1%). The script used looks like this: >> >> for o3 in `seq 1 254`; do >> for o4 in `seq 1 254`; do >> host=127.0.$o3.$o4 >> openssl s_client -ssl3 -connect $host:4433 & >> done >> sleep 1 >> done >> >> the server side is like this: openssl s_server > > Please correct me if I'm wrong, but if I remember correctly, s_server > only handles single SSL connection at the time. The next connection is > only accepted (SSL handshake) when the existing connection is closed. > I'd expect the above test to open 1 SSL connection to s_server, with > bunch of other s_client connections being established, but waiting for > SSL handshake. This does not sound like a valid test case. Seems like you are right! Do you have any good methord to test this? Any advice would be appreciated! Regards, Guanjun ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
