IETF Logo Mail Archive

Re: [TLS] SSL Renegotiation DOS

Joe Orton <jorton@redhat.com> Tue, 15 March 2011 15:38 UTC

Return-Path: <jorton@redhat.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 1214A3A6D4B for <tls@core3.amsl.com>; Tue, 15 Mar 2011 08:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 PBNkaLHoz3Yu for <tls@core3.amsl.com>; Tue, 15 Mar 2011 08:38:31 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id 3DC593A6D1F for <tls@ietf.org>; Tue, 15 Mar 2011 08:38:31 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p2FFdl6K010903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Mar 2011 11:39:47 -0400
Received: from turnip.manyfish.co.uk (vpn-11-233.rdu.redhat.com [10.11.11.233]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p2FFdiuW015707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Mar 2011 11:39:45 -0400
Received: from jorton by turnip.manyfish.co.uk with local (Exim 4.72) (envelope-from <jorton@redhat.com>) id 1PzWLX-0002fe-B7; Tue, 15 Mar 2011 15:39:43 +0000
Date: Tue, 15 Mar 2011 15:39:43 +0000
From: Joe Orton <jorton@redhat.com>
To: Steve Dispensa <dispensa@phonefactor.com>
Message-ID: <20110315153943.GA10156@redhat.com>
Mail-Followup-To: Steve Dispensa <dispensa@phonefactor.com>, Nikos Mavrogiannopoulos <nmav@gnutls.org>, "Jorge A. Orchilles" <jorge@orchilles.com>, tls@ietf.org
References: <AANLkTin2i3+K8oV68pZFJ0xabjEugJLePyZTTaZSr0VE@mail.gmail.com> <AANLkTimVvBOdX9JNXE+JyZS5vTHsXnfhQMAH2cTgTRfM@mail.gmail.com> <0F7F9A82BB0DBB4396A9F8386D0E061206623016@pos-exch1.corp.positivenetworks.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <0F7F9A82BB0DBB4396A9F8386D0E061206623016@pos-exch1.corp.positivenetworks.net>
User-Agent: Mutt/1.5.20 (2009-12-10)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
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 15:38:32 -0000

On Tue, Mar 15, 2011 at 08:23:44AM -0500, Steve Dispensa wrote:
> >  I'm curious, what is the effect of that in typical HTTPS servers? 
> > Do servers allow for renegotiation initiated by the client? (apache 
> > with mod_gnutls doesn't)
> 
> When we looked at implementations last year, we found that IIS was 
> definitely not willing to do client-initiated renegotiation, but at 
> the time there were a few that would. I'm sure a lot has changed since 
> I last looked at it.

As part of the workaround for CVE-2009-3555 added in the 2.2.15 release 
of Apache httpd, mod_ssl will (or should!) reject any renegotiation 
initiated by the client.  The code still behaves this way, for both 
clients which support RFC 5746 and those which do not.

Older versions of Apache httpd/mod_ssl will allow a client-initiated 
reneg at any time, as is the default behaviour with OpenSSL-based 
servers.

I recall a complaint that some mobile browser was known to initiate 
renegs, but I can't find a reference for that; it might have been 
off-line discussion.  I'd be interested to hear any further data on 
that.

Regards, Joe

v2.23.0 | Report a Bug | By Email