Re: [TLS] SSL Renegotiation DOS

Eric Rescorla <ekr@rtfm.com> Tue, 15 March 2011 16:19 UTC

Return-Path: <ekr@rtfm.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 47A923A6C5B for <tls@core3.amsl.com>; Tue, 15 Mar 2011 09:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.934
X-Spam-Level:
X-Spam-Status: No, score=-102.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 zQZzZ+HDqBgK for <tls@core3.amsl.com>; Tue, 15 Mar 2011 09:19:10 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 2A2BA3A6B89 for <tls@ietf.org>; Tue, 15 Mar 2011 09:19:10 -0700 (PDT)
Received: by iyi12 with SMTP id 12so863973iyi.31 for <tls@ietf.org>; Tue, 15 Mar 2011 09:20:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.135.73 with SMTP id if9mr9676079icc.37.1300206035277; Tue, 15 Mar 2011 09:20:35 -0700 (PDT)
Received: by 10.42.217.2 with HTTP; Tue, 15 Mar 2011 09:20:35 -0700 (PDT)
In-Reply-To: <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp>
References: <AANLkTin2i3+K8oV68pZFJ0xabjEugJLePyZTTaZSr0VE@mail.gmail.com> <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp>
Date: Tue, 15 Mar 2011 09:20:35 -0700
Message-ID: <AANLkTikXumkgN8AGs_kPQJy2Bs7sG2HuGnrHTA4HCwxu@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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:19:13 -0000

On Tue, Mar 15, 2011 at 9:07 AM, Martin Rex <mrex@sap.com> wrote:
> Jorge A. Orchilles wrote:
>>
>> Marsh Ray has invited me to present my research and report on SSL/TLS
>> Renegotiation Denial of Service on this mailing list. I have posted this on
>> my site and will paste here for your feedback:
>> http://orchilles.com/2011/03/ssl-renegotiation-dos.html
>>
>> *SSL/TLS Renegotiation Denial of Service*
>>
>> An SSL/TLS handshake requires at least 10 times more processing power on the
>> server than on the client.
>
> I'm sorry, I completely fail to see what renegotiation has to do
> with the DoS capability here.
>
> The TLS protocol is a cryptographic protocol, and servers that expect
> to talk to real clients performing the protocol as designed will attempt
> to perform the cryptographic operations as requested.
>
> 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.

I tend to agree with Martin here: I don't see how this is
significantly worse than separate
connections. 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.

-Ekr