Re: [TLS] SSL Renegotiation DOS

Marsh Ray <marsh@extendedsubset.com> Tue, 15 March 2011 16:35 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F3B13A6A7C for <tls@core3.amsl.com>; Tue, 15 Mar 2011 09:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2tFLAkfbuG6 for <tls@core3.amsl.com>; Tue, 15 Mar 2011 09:35:46 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id A76D23A6D7D for <tls@ietf.org>; Tue, 15 Mar 2011 09:35:39 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1PzWw1-000Jq5-Vr; Tue, 15 Mar 2011 16:17:26 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 653EC6068; Tue, 15 Mar 2011 16:36:58 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+n6RWUZpllMV4emFbki71wQWvfrXjNKTk=
Message-ID: <4D7F95AA.8060007@extendedsubset.com>
Date: Tue, 15 Mar 2011 11:36:58 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
References: <AANLkTin2i3+K8oV68pZFJ0xabjEugJLePyZTTaZSr0VE@mail.gmail.com> <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp> <AANLkTikXumkgN8AGs_kPQJy2Bs7sG2HuGnrHTA4HCwxu@mail.gmail.com>
In-Reply-To: <AANLkTikXumkgN8AGs_kPQJy2Bs7sG2HuGnrHTA4HCwxu@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] SSL Renegotiation DOS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2011 16:35:47 -0000

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