SSL related DoS

[Chris Hill <ch...@gmail.com>]

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

[Erwann ABALEA <ea...@gmail.com>]

2011/4/16 Chris Hill <ch...@gmail.com>:
[...]
> 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).

This 15x between server and client is for a small modulus key (<1024).
As the modulus gets larger, the ratio grows also. On my Core i5 Mac,
the ratio is 35x for a 2048bits RSA key.

This is also valid only for RSA, and only for "classic" keys, ones
with a small exponent.

Switch to DSA, and verification takes more time than signature. Switch
to ECDSA, and you'll even reduce your CPU usage. That will cost you a
DH/ECDH key agreement, but with the actual version of thc-ssl-dos, the
client will also suffer from it.

If you're afraid some of your clients don't know DSA/ECDSA, then stay
with RSA, but generate a key with a large public exponent (make it the
same size as the modulus). That way, encryptions and verifications
(done on client side) won't be accelerated, and the ratio is no more
35x, but only 1.4x (fast measurement on my machine, unoptimized). I'm
sure one can gain a little bit more, maybe even reverse the speed
ratio.

-- 
Erwann.

Re: SSL related DoS

[Chris Hill <ch...@gmail.com>]

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 <tr...@gmail.com> wrote:

> On Sat, Apr 16, 2011 at 3:39 PM, Daniel Ruggeri <DR...@primary.net>
> 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

[Jeff Trawick <tr...@gmail.com>]

On Sat, Apr 16, 2011 at 3:39 PM, Daniel Ruggeri <DR...@primary.net> 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

[Chris Hill <ch...@gmail.com>]

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. <wr...@rowe-clan.net> 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.
>
>

Re: SSL related DoS

[Stefan Fritsch <sf...@sfritsch.de>]

On Sat, 16 Apr 2011, Eric Covener wrote:

> would mod_reqtimeout step in after too many renegotiations had eaten
> too much wall time?

Whenever mod_ssl reads data from the client, mod_reqtimeout will check the 
configured timeouts. It is possible that the data sent during reneg may 
prevent the "minimum required data rate" feature from triggering, but 
maximum timeouts will always be enforced.

The attacker can just create new connections, though.

Re: SSL related DoS

[Eric Covener <co...@gmail.com>]

would mod_reqtimeout step in after too many renegotiations had eaten
too much wall time?

Re: SSL related DoS

["William A. Rowe Jr." <wr...@rowe-clan.net>]

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.

Re: SSL related DoS

[Daniel Ruggeri <DR...@primary.net>]

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.

-- 
--
Daniel Ruggeri