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
>