Re: [TLS] TLS or HTTP issue? (was: TLS renegotiation issue)

Nathaniel W Filardo <> Fri, 06 November 2009 17:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81C6C3A68E8 for <>; Fri, 6 Nov 2009 09:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xLlVvrjT2xo5 for <>; Fri, 6 Nov 2009 09:49:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 150133A68F7 for <>; Fri, 6 Nov 2009 09:49:06 -0800 (PST)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id nA6HnPpR018685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Nov 2009 12:49:25 -0500 (EST)
Received: from (localhost.localdomain []) by (8.14.2/8.13.1) with ESMTP id nA6HnPEX012225; Fri, 6 Nov 2009 12:49:25 -0500
Received: (from nwf@localhost) by (8.14.2/8.13.8/Submit) id nA6HnO2f012224; Fri, 6 Nov 2009 12:49:24 -0500
Date: Fri, 6 Nov 2009 12:49:24 -0500
From: Nathaniel W Filardo <>
To: Nicolas Williams <>
Message-ID: <>
References: <> <> <20091106172323.GY1105@Sun.COM>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8rALO501tkk3VWH"
Content-Disposition: inline
In-Reply-To: <20091106172323.GY1105@Sun.COM>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Eric Rescorla <>, "" <>
Subject: Re: [TLS] TLS or HTTP issue? (was: TLS renegotiation issue)
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, 06 Nov 2009 17:49:07 -0000

On Fri, Nov 06, 2009 at 11:23:23AM -0600, Nicolas Williams wrote:
> This vulnerability will affect different application protocols
> differently.  It certainly affects HTTP.  I think LDAP may not be
> susceptible, but I'm not sure; I'm even less sure about IMAP.  Others
> have indicated that there definitely exist other applications besides
> HTTP which do suffer from this vulnerability though, and that's the key:
> of course there may be more than one application protocol that is made
> vulnerable by this TLS problem.
> We must fix this problem in TLS itself.  The fix may require changes to
> some applications, depending not so much on the protocol as on the TLS
> API used.
> Nico

Forgive me if I'm mistaken, but as far as I understand (one of) the
attack(s), it relies on an application protocol (e.g. HTTP) request being
'fragmented' across the renegotiation (thus the need for, in HTTP, the
attacker-provided X-Swallow-This: header to absorb the client's GET)...

Is it in general sufficient for the server to initiate the reauthentication
only in response to a complete request?  Alternatively, in the case of HTTP,
is it sufficient to reject requests with client-provided headers (i.e.
anything except the GET/POST/... line) on the outer connection?  That is,
are there any clients which actually depend on being able to fragment
requests like this?

Just curious.  Thanks.