Re: [TLS] SSL Renegotiation DOS

I think a solution would be to only allow a certain amount of renegotiations
per a given period.

Best Regards,
Jorge Orchilles

On Tue, Mar 15, 2011 at 1:36 PM, Marsh Ray <marsh@extendedsubset.com> wrote:

> On 03/15/2011 11:20 AM, Eric Rescorla wrote:
>
>> On Tue, Mar 15, 2011 at 9:07 AM, Martin Rex<mrex@sap.com>  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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>