Re: [TLS] SSL Renegotiation DOS

[Marsh Ray <[e-mail]>]

On 03/15/2011 11:20 AM, Eric Rescorla wrote:
> On Tue, Mar 15, 2011 at 9:07 AM, Martin Rex<[e-mail]>  wrote:
>>
>> I'm sorry, I completely fail to see what renegotiation has to do
>> with the DoS capability here.
>> [...]
>> A DoS-client could simply open new connections to the SSL server
>> and blindly fire away precompiled static SSL handshake messages,
>> forcing the server to do crypto work.  You should be able to make
>> most servers perform RSA decrypts on arbitrary data, and a
>> significant number to perform DHE computations.

Yes, but take a step back from the code for a minute. This is a 
potential problem, and the degree to which this is "not my (TLS's) 
problem" has to do mainly with how close you are to the web server 
getting DoSed.

> I tend to agree with Martin here: I don't see how this is
> significantly worse than separate connections.

Presumably, somewhere there is a TCP-based load-balancing DoS prevention 
system protecting a TLS server that allows client-initiated 
renegotiation. This system may do a good job of resisting DoSes on the 
initial handshake but not DoSes on renegotiation handshakes.

My suggestion to Jorge would be to find such a product configuration and 
demonstrate the attack against it (and file a bug with the vendor of 
course).

I don't see this as a real weakness in TLS itself either. Nevertheless, 
I think might be something in scope here. Are there improvements to DoS 
resistance which could be made in the scope of the IETF's TLS activity?

For those of us wishing to promote the use of TLS/HTTPS in general, is 
susceptibility to DoS a significant barrier to adoption?

Look at it this way: If adding TLS increasing the susceptibility to DoS 
attacks, could a DoS be used to compel a site operator to turn off 
encryption? If so, is this not effectively an equivalent to a weakness 
in TLS itself?

> Arguably, it's better
> from the victim's perspective, since common implementations run each
> SSL/TLS connection in its own control thread (or process) and so the
> scheduler will try to fairly share between connections to some extent
> meaning that the single offending connection is bounded in terms of
> how much it can affect other users.

That's an interesting point.

- Marsh