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. You also seem to store IP as 32bit value, which does not sound like it should work correctly for IPv6. 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. HTH -- Tomas Hoger ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
