re: SSL related DoS
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. If you want to protect some parts of your site with client authentication, then you need to enable insecure renegotiation to support (not so) old browsers - even latest version of Safari on Mac. But I agree it should stay disabled by default (most secure). And client-side renegotiation isn't probably needed as several app servers do not honour it any way. Nick
Re: SSL related DoS
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
On Sat, Apr 16, 2011 at 3:39 PM, Daniel Ruggeri drugg...@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
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 traw...@gmail.com wrote:
On Sat, Apr 16, 2011 at 3:39 PM, Daniel Ruggeri drugg...@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
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
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
Re: SSL related DoS
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
would mod_reqtimeout step in after too many renegotiations had eaten too much wall time?
Re: SSL related DoS
2011/4/16 Chris Hill chris.hill...@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.
