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.