Re: [TLS] SSL Renegotiation DOS

"Jorge A. Orchilles" <jorge@orchilles.com> Fri, 18 March 2011 23:23 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 B39863A6A8C for <tls@core3.amsl.com>; Fri, 18 Mar 2011 16:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.73
X-Spam-Level:
X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[AWL=0.246, 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 zypO2990JWAw for <tls@core3.amsl.com>; Fri, 18 Mar 2011 16:23:35 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5A9E33A6A6A for <tls@ietf.org>; Fri, 18 Mar 2011 16:23:33 -0700 (PDT)
Received: by fxm15 with SMTP id 15so4465023fxm.31 for <tls@ietf.org>; Fri, 18 Mar 2011 16:25:02 -0700 (PDT)
Received: by 10.223.69.131 with SMTP id z3mr399159fai.91.1300489881952; Fri, 18 Mar 2011 16:11:21 -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 17sm1574073far.19.2011.03.18.16.11.20 (version=SSLv3 cipher=OTHER); Fri, 18 Mar 2011 16:11:21 -0700 (PDT)
Received: by fxm15 with SMTP id 15so4458824fxm.31 for <tls@ietf.org>; Fri, 18 Mar 2011 16:11:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.30.77 with SMTP id t13mr1910851fac.112.1300489880317; Fri, 18 Mar 2011 16:11:20 -0700 (PDT)
Received: by 10.223.98.205 with HTTP; Fri, 18 Mar 2011 16:11:20 -0700 (PDT)
In-Reply-To: <4D7F95AA.8060007@extendedsubset.com>
References: <AANLkTin2i3+K8oV68pZFJ0xabjEugJLePyZTTaZSr0VE@mail.gmail.com> <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp> <AANLkTikXumkgN8AGs_kPQJy2Bs7sG2HuGnrHTA4HCwxu@mail.gmail.com> <4D7F95AA.8060007@extendedsubset.com>
Date: Fri, 18 Mar 2011 20:11:20 -0300
Message-ID: <AANLkTikGA=5txf1v-FKBdkzu2XSxyQ_xJ1dbUYZnb9ZD@mail.gmail.com>
From: "Jorge A. Orchilles" <jorge@orchilles.com>
To: Marsh Ray <marsh@extendedsubset.com>
Content-Type: multipart/alternative; boundary=00151744876859ae7b049ec9e550
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:23:39 -0000

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
>