Re: [TLS] SSL Renegotiation DOS

"Jorge A. Orchilles" <jorge@orchilles.com> Fri, 18 March 2011 23:07 UTC

Return-Path: <jorge@orchilles.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 239463A6A8D for <tls@core3.amsl.com>; Fri, 18 Mar 2011 16:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.533
X-Spam-Level:
X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 uwotQt66INQW for <tls@core3.amsl.com>; Fri, 18 Mar 2011 16:07:20 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5E8D73A6A8C for <tls@ietf.org>; Fri, 18 Mar 2011 16:07:20 -0700 (PDT)
Received: by bwz13 with SMTP id 13so4106702bwz.31 for <tls@ietf.org>; Fri, 18 Mar 2011 16:08:49 -0700 (PDT)
Received: by 10.204.15.75 with SMTP id j11mr1467351bka.20.1300489729208; Fri, 18 Mar 2011 16:08:49 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx.google.com with ESMTPS id x6sm2505635bkv.0.2011.03.18.16.08.48 (version=SSLv3 cipher=OTHER); Fri, 18 Mar 2011 16:08:48 -0700 (PDT)
Received: by fxm15 with SMTP id 15so4457611fxm.31 for <tls@ietf.org>; Fri, 18 Mar 2011 16:08:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.44.89 with SMTP id z25mr1453236fae.74.1300489727291; Fri, 18 Mar 2011 16:08:47 -0700 (PDT)
Received: by 10.223.98.205 with HTTP; Fri, 18 Mar 2011 16:08:47 -0700 (PDT)
In-Reply-To: <AANLkTikXumkgN8AGs_kPQJy2Bs7sG2HuGnrHTA4HCwxu@mail.gmail.com>
References: <AANLkTin2i3+K8oV68pZFJ0xabjEugJLePyZTTaZSr0VE@mail.gmail.com> <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp> <AANLkTikXumkgN8AGs_kPQJy2Bs7sG2HuGnrHTA4HCwxu@mail.gmail.com>
Date: Fri, 18 Mar 2011 20:08:47 -0300
Message-ID: <AANLkTim2nhKPTRRnJLTM0AvkjJiFk3x-7r2mmu4v62Z3@mail.gmail.com>
From: "Jorge A. Orchilles" <jorge@orchilles.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=0015174761ce3ab032049ec9dc26
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: Fri, 18 Mar 2011 23:07:22 -0000

It is different that you don't need the volume that you typically need for
DDOS. With renogatiation the attacker can request the server to do all the
crypto work by requesting multiple handshakes per second.

Best Regards,
Jorge Orchilles



On Tue, Mar 15, 2011 at 1:20 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> 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
>