Re: [TLS] SSL Renegotiation DOS

"Jorge A. Orchilles" <jorge@orchilles.com> Fri, 18 March 2011 23:18 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 DC2AC3A6A8C for <tls@core3.amsl.com>; Fri, 18 Mar 2011 16:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=0.277, 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 MqTd1dfy6HOY for <tls@core3.amsl.com>; Fri, 18 Mar 2011 16:18:32 -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 7215A3A6A6A for <tls@ietf.org>; Fri, 18 Mar 2011 16:18:31 -0700 (PDT)
Received: by bwz13 with SMTP id 13so4111758bwz.31 for <tls@ietf.org>; Fri, 18 Mar 2011 16:20:00 -0700 (PDT)
Received: by 10.204.136.1 with SMTP id p1mr1446689bkt.105.1300490400615; Fri, 18 Mar 2011 16:20:00 -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 x6sm2510991bkv.0.2011.03.18.16.19.59 (version=SSLv3 cipher=OTHER); Fri, 18 Mar 2011 16:20:00 -0700 (PDT)
Received: by fxm15 with SMTP id 15so4462861fxm.31 for <tls@ietf.org>; Fri, 18 Mar 2011 16:19:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.6.73 with SMTP id 9mr1581679fay.131.1300490066952; Fri, 18 Mar 2011 16:14:26 -0700 (PDT)
Received: by 10.223.98.205 with HTTP; Fri, 18 Mar 2011 16:14:26 -0700 (PDT)
In-Reply-To: <E1PzkdD-0000jT-4G@login01.fos.auckland.ac.nz>
References: <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp> <E1PzkdD-0000jT-4G@login01.fos.auckland.ac.nz>
Date: Fri, 18 Mar 2011 20:14:26 -0300
Message-ID: <AANLkTinryUaNNaUi=csoQpQbVoAW8p2OgarNA0t32t7Z@mail.gmail.com>
From: "Jorge A. Orchilles" <jorge@orchilles.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary=00151747b3807982ff049ec9f0be
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:18:32 -0000

I have password protected the post on my blog because of this. I have
confirmed this is an issue and many sites are vulnerable to DOS. I am
reporting to vendor and vulnerable sites. Until then I will keep the post
locked. You can email me individually for the password as this mailing list
is public and I continue to update the post based on feedback and tests.

Best Regards,
Jorge Orchilles



On Wed, Mar 16, 2011 at 3:54 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz>wrote;wrote:

> Martin Rex <mrex@sap.com> writes:
>
> >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.
>
> Exactly.  You can do this with virtually no effort using netcat, I continue
> to
> be surprised that we've never seen this deployed in the wild (not wanting
> to
> give any hints to Anonymous, but LOIC is 1990s script-kiddie technology
> compared to the DoSes you could use if you gave it a few minutes thought).
> What makes it even worse is the Bleichenbacher-attack defense that says you
> have to complete the handshake, at full crypto cost, even if it's obvious
> that
> you're just processing garbage.
>
> (Every time this comes up I'm tempted to release some quick tool to exploit
> the problem, on the basis that if the good guys don't point it out now, the
> bad guys will take advantage of it later.  So far I've resisted the
> temptation...).
>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>