Re: [TLS] SSL Renegotiation DOS
"Jorge A. Orchilles" <jorge@orchilles.com> Fri, 18 March 2011 23:17 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 9B3BE3A6A92 for <tls@core3.amsl.com>; Fri, 18 Mar 2011 16:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.659
X-Spam-Level:
X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.317, 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 2BzvulMCbZ+S for <tls@core3.amsl.com>; Fri, 18 Mar 2011 16:17:13 -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 032323A6A8C for <tls@ietf.org>; Fri, 18 Mar 2011 16:17:12 -0700 (PDT)
Received: by fxm15 with SMTP id 15so4462220fxm.31 for <tls@ietf.org>; Fri, 18 Mar 2011 16:18:42 -0700 (PDT)
Received: by 10.223.143.12 with SMTP id s12mr507282fau.121.1300490308497; Fri, 18 Mar 2011 16:18:28 -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 c11sm1573999fav.26.2011.03.18.16.18.27 (version=SSLv3 cipher=OTHER); Fri, 18 Mar 2011 16:18:27 -0700 (PDT)
Received: by fxm15 with SMTP id 15so4462078fxm.31 for <tls@ietf.org>; Fri, 18 Mar 2011 16:18:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.6.73 with SMTP id 9mr1580376fay.131.1300489965895; Fri, 18 Mar 2011 16:12:45 -0700 (PDT)
Received: by 10.223.98.205 with HTTP; Fri, 18 Mar 2011 16:12:45 -0700 (PDT)
In-Reply-To: <201103151757.p2FHvIRC014976@fs4113.wdf.sap.corp>
References: <4D7F95AA.8060007@extendedsubset.com> <201103151757.p2FHvIRC014976@fs4113.wdf.sap.corp>
Date: Fri, 18 Mar 2011 20:12:45 -0300
Message-ID: <AANLkTik4dJFBqH5L+WjBhnuL=jJOTq5jESydBgkXEart@mail.gmail.com>
From: "Jorge A. Orchilles" <jorge@orchilles.com>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary="00151747b380737ef5049ec9ea1b"
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:17:14 -0000
However many servers continue to allow SSL Renegotiation. I am identifying what implementations, suites and web servers allow this and reporting it to the vendor and site. Best Regards, Jorge Orchilles On Tue, Mar 15, 2011 at 2:57 PM, Martin Rex <mrex@sap.com> wrote: > Marsh Ray wrote: > > > > > > 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. > > The issue might be more about the classification of what counts as > a DoS attack. Recognizing TLS renegotiations is technically possible for > Intrusion dectection systems, since the ChangeCipherSpec handshake > message remains visible on on the wire, even for TLS renegotiations. > (also, the fact that handshake messages rather than application data > is exchanged, remains visible on the wire). > > The workload impact of full TLS handshakes on the TLS server is > far from marginal. Therefore, even non-hostile clients can consume > most of a servers resources. > > Distinguishing DoS from clients with a flaw in their TLS session caching > and defective server-side TLS session caching or inappropriate > configuration > might be tricky for an IDS. Server resources may get drained without any > errors showing up on the communication protocol level, simply by > performing the cryptographic operations of the protocol over and over > again. > > A TLS server can easily DoS _itself_ with an inadequate, > too small or disabled server side TLS session cache (or due to > bugs in the session cache management of the implementation). > > Personally, I consider it a bad idea to run a TLS server on the > internet with TLS session caching entirely disabled. Limiting > session cache lifetime and session cache size on the TLS server > seems sensible, but running entirely without session cache > does not look sensible to me (for public Web-Servers on the internet). > > TLS clients without session caching capabilities also seem to > be unnecessarily common. Apache mod_proxy used to be incapable > of client side TLS session caching--which causes a serious > performance impact on the communication link between reverse > proxy and backend if that link is TLS-reencrypted. > > > > > 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? > > When the topic of "client identity protection" came up on the TLS > mailing list, the suggestion was made to solve this by performing > a TLS renegotiation. > > Today (after the TLS renegotiation vulnerability), many servers may > have unsolicited renegotiations disabled (and may continue to have > it disabled after adopting the rfc5746 solution). Microsoft IIS > seems to have never supported unsolicited renegotiations so far -- > it was primarily "added value" for TLS implementations that could > perform TLS renegotiation "transparently", i.e. without requiring > support from the (TLS) application caller to do renegotiation. > > The results that TLS renegotiation might have on the client identity, > as seen by the server application, is sufficiently non-trivial that some > discussion on this was added to the security considerations of rfc5746 > > http://tools.ietf.org/html/rfc5746#section-5 > > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- Re: [TLS] SSL Renegotiation DOS Jorge A. Orchilles
- [TLS] SSL Renegotiation DOS Jorge A. Orchilles
- Re: [TLS] SSL Renegotiation DOS Nikos Mavrogiannopoulos
- Re: [TLS] SSL Renegotiation DOS Steve Dispensa
- Re: [TLS] SSL Renegotiation DOS Joe Orton
- Re: [TLS] SSL Renegotiation DOS Dr Stephen Henson
- Re: [TLS] SSL Renegotiation DOS Steve Dispensa
- Re: [TLS] SSL Renegotiation DOS Martin Rex
- Re: [TLS] SSL Renegotiation DOS Eric Rescorla
- Re: [TLS] SSL Renegotiation DOS Marsh Ray
- Re: [TLS] SSL Renegotiation DOS Martin Rex
- Re: [TLS] SSL Renegotiation DOS Steve Dispensa
- Re: [TLS] SSL Renegotiation DOS Peter Gutmann
- Re: [TLS] SSL Renegotiation DOS Martin Rex
- Re: [TLS] SSL Renegotiation DOS Peter Gutmann
- Re: [TLS] SSL Renegotiation DOS Jorge A. Orchilles
- Re: [TLS] SSL Renegotiation DOS Jorge A. Orchilles
- Re: [TLS] SSL Renegotiation DOS Jorge A. Orchilles
- Re: [TLS] SSL Renegotiation DOS Jorge A. Orchilles
- Re: [TLS] SSL Renegotiation DOS Jorge A. Orchilles