On Wed, 11 Jan 2012 21:04:33 -0700 Guan Jun He wrote: > > 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'.
The issue is about renegotiations. If the fix allows all initial handshakes and only penalizes all connections that do many rehanshakes, there's no DoS as you suggest and should be sufficient to address CVE-2011-1473. > > 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? You want something that does not block rehandshakes. s_server should be sufficient if you're only after limiting renegotiations within one connection. httpd blocks client-initiated renegotiation for a while. stunnel may work as a good target. You probably want to look at something using custom BIO too. -- Tomas Hoger ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
