httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hill <>
Subject SSL related DoS
Date Sat, 16 Apr 2011 16:52:56 GMT
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:

*Previous Apache Thread*:
(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

*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:  ->DDoS
protection strategy which mentions some of the above points
-> Shows how IDS vendors are starting to look at this as a way to stop DoS



View raw message