Re: [TLS] SSL Renegotiation DOS

"Jorge A. Orchilles" <> Fri, 18 March 2011 23:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B3BE3A6A92 for <>; Fri, 18 Mar 2011 16:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.659
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2BzvulMCbZ+S for <>; Fri, 18 Mar 2011 16:17:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 032323A6A8C for <>; Fri, 18 Mar 2011 16:17:12 -0700 (PDT)
Received: by fxm15 with SMTP id 15so4462220fxm.31 for <>; Fri, 18 Mar 2011 16:18:42 -0700 (PDT)
Received: by with SMTP id s12mr507282fau.121.1300490308497; Fri, 18 Mar 2011 16:18:28 -0700 (PDT)
Received: from ( []) by with ESMTPS id c11sm1573999fav.26.2011. (version=SSLv3 cipher=OTHER); Fri, 18 Mar 2011 16:18:27 -0700 (PDT)
Received: by fxm15 with SMTP id 15so4462078fxm.31 for <>; Fri, 18 Mar 2011 16:18:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id 9mr1580376fay.131.1300489965895; Fri, 18 Mar 2011 16:12:45 -0700 (PDT)
Received: by with HTTP; Fri, 18 Mar 2011 16:12:45 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Fri, 18 Mar 2011 20:12:45 -0300
Message-ID: <>
From: "Jorge A. Orchilles" <>
Content-Type: multipart/alternative; boundary="00151747b380737ef5049ec9ea1b"
Subject: Re: [TLS] SSL Renegotiation DOS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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
> -Martin
> _______________________________________________
> TLS mailing list