SSL related DoS
Dear Apache httpd dev list, There have been previous posts on this topic (I've initiated some in both OpenSSL and Apache mailing lists), but I'd like to now just narrow the topic down to what seems to be the most relevant points for which there are not yet answers. We need you (the smart folks ;) to help us figure out how to stop script kiddies from keep taking down our sites using published tools. For those unfamiliar, these are some of useful references: *IETF*: http://old.nabble.com/SSL-Renegotiation-DOS-td31152893.html *Previous Apache Thread*: http://old.nabble.com/Fwd%3A-Client-Initiated-Renegotiation-after-0.9.8l-td31395063.html (This was started from my post to the OpenSSL dev list). *The problem*: DoS in general (and to an extent DDoS) against an SSL enabled sites/protocols (and not just OpenSSl based or Apache) AND the fact that software does not seem to be designed with "preventive controls" in mind to alleviate some of this (even if optional). SSL handshakes take more processing power in the server side than on the client side (some commented in the order of 15x more). This is great news for attackers who want to take down a site and the work has already be done for them through recent exploits developed by the THC (exploiting specifically the fact that a single workstation can initiate 200-1000 secure renegotiations per second and take down a robust sites). *POINT 1.* One of the points where the previous threads seem to end is whether client initiated renegotiation is indeed more effective (DoS wise) than the initial handshake abuse (a guy starting and terminating a bunch of connections at once). I tend to be on the side that believes that client initiated renegs lend themselves to abuse because a client has to do less work to request many of these per second since they can leverage the same TCP connections, avoiding the TCP handshake altogether. Now, I don’t yet have a way to quantify this. *This would be a great experiment for folks with good programming skills. THC already took care of the Renegotiation DoS POC.* *POINT 2.* I would think much of our protection for such attacks (e.g. IDS/IPS) or even resource management would be at the initial TCP connection level than higher up in the technology stack. I believe Joe mentioned this on one of the above posts “MaxKeepAliveRequests to some degree bounds resource usage per TCP connection a HTTP level; there's no equivalent to bound CPU usage due to renegs. I'm not sure this is a particularly solid argument though.” The reason why I insist in this is that the world has come to depend on HTTP/SOAP over SSL (and Apache/OpenSSL are probably the most popular implementation) for business critical apps, yet, it is not clear how these businesses can play around with configuration parameters to fine tune these SSL settings to their specific needs, e.g. *ensure client side renegs can be disabled* or at least,* provide a way of limiting how many of these a client initiated re-negotiations (or initial handshakes) a server will allow per second for a specific connection/IP*. It is great that recent Apache builds disable client initiated renegotiation by default, but how can I ensure this will never be turned back on in future releases given the lack of configuration parameters? I know of specific vendors (I will not reveal their names here) whose products are used widely for critical scenarios and the THC attack would not only kick them out of the Internet, but they would actually reboot at times! Some other references: http://www.rakkhis.com/2011/03/ddos-protection-strategies.html ->DDoS protection strategy which mentions some of the above points http://services.netscreen.com/documentation/signatures/SSL%3ATHC-SSL-DOS.html -> Shows how IDS vendors are starting to look at this as a way to stop DoS Thanks, Chris.
Re: SSL related DoS
Yes, disabled by default now. My point was just make sure it did not come back again, at least not without a config parameter to easily disable/enable. On Sun, Apr 17, 2011 at 8:41 AM, Jeff Trawick wrote: > On Sat, Apr 16, 2011 at 3:39 PM, Daniel Ruggeri > wrote: > > On 4/16/2011 11:52 AM, Chris Hill wrote: > >> > >> Dear Apache httpd dev list, > >> ... > >> The reason why I insist in this is that the world has come to depend on > >> HTTP/SOAP over SSL (and Apache/OpenSSL are probably the most popular > >> implementation) for business critical apps, yet, it is not clear how > >> these businesses can play around with configuration parameters to fine > >> tune these SSL settings to their specific needs, e.g. *ensure client > >> side renegs can be disabled* or at least,*provide a way of limiting how > >> many of these a client initiated re-negotiations (or initial handshakes) > >> a server will allow per second for a specific connection/IP*. It is > >> great that recent Apache builds disable client initiated renegotiation > >> by default, but how can I ensure this will never be turned back on in > >> future releases given the lack of configuration parameters? > >> > > > > Chris; > > I believe this topic (enable/disable renegotiation) was brought up on > this > > list just a matter of days ago. I don't recall seeing a consensus, but I > > would agree that a configuration parameter to (dis)allow client-initiated > > renegotiation would be a Very Good Thing. I don't think this would be > very > > difficult to implement - and would be a good start to correct the issues > you > > call out. > > I thought client-initiated renegotiation was already disabled out of > the box, with no configuration mechanism to re-enable. > > From ssl_engine_kernel.c, 2.2.x-latest: > >/* If the first handshake is complete, change state to reject any > * subsequent client-initated renegotiation. */ >else if ((where & SSL_CB_HANDSHAKE_DONE) && scr->reneg_state == > RENEG_INIT) { >scr->reneg_state = RENEG_REJECT; >} >
Re: SSL related DoS
Bill, that is already good, but then the question still remains of whether there is something that can be done disable/control/detect too many handshakes from any given client (new or renegotiated). I'd love to understand whether this is even a reasonable thing discuss, as I do not have knowledge of the Internals of Apache/OpenSSL. On Saturday, April 16, 2011, William A. Rowe Jr. wrote: > On 4/16/2011 2:39 PM, Daniel Ruggeri wrote: >> On 4/16/2011 11:52 AM, Chris Hill wrote: >>> but how can I ensure this will never be turned back on in >>> future releases given the lack of configuration parameters? >> >> Chris; >> I believe this topic (enable/disable renegotiation) was brought up on >> this list just a >> matter of days ago. I don't recall seeing a consensus, but I would agree >> that a >> configuration parameter to (dis)allow client-initiated renegotiation would >> be a Very Good >> Thing. I don't think this would be very difficult to implement - and would >> be a good start >> to correct the issues you call out. > > One, there are no assurances. But today, renegotiation will not > work out of the box *without* SSLInsecureRenegotation... > > The group consensus seems to be that introducing 'new' safe client > renegotiation will come at the cost of a new directive to -enable- it, > leaving it disabled, by default. The group seems to generally doubt > that there is any DoS (SSL is resource intensive, new connections and > renegotiated connections are equally so), but there doesn't seem to be > any immediate demand for renegotiation support, so it makes the most > sense to leave it optional-to-enable rather than optional-to-disable. > >