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

Nicolas Williams <> Fri, 06 November 2009 19:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78A2928C116 for <>; Fri, 6 Nov 2009 11:25:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.017
X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MZoSHlTrGm4L for <>; Fri, 6 Nov 2009 11:25:11 -0800 (PST)
Received: from (brmea-mail-1.Sun.COM []) by (Postfix) with ESMTP id 3CE5B3A62C1 for <>; Fri, 6 Nov 2009 11:25:10 -0800 (PST)
Received: from ([]) by (8.13.6+Sun/8.12.9) with ESMTP id nA6JPWDo021829 for <>; Fri, 6 Nov 2009 19:25:33 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM []) by (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nA6JPViq034660 for <>; Fri, 6 Nov 2009 12:25:32 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost []) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA6Ix0Qa010243; Fri, 6 Nov 2009 12:59:00 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6Ix0Bd010242; Fri, 6 Nov 2009 12:59:00 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to using -f
Date: Fri, 6 Nov 2009 12:59:00 -0600
From: Nicolas Williams <>
To: Nathaniel W Filardo <>
Message-ID: <20091106185859.GA1105@Sun.COM>
References: <> <> <20091106172323.GY1105@Sun.COM> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.7i
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 19:25:12 -0000

On Fri, Nov 06, 2009 at 12:49:24PM -0500, Nathaniel W Filardo wrote:
> 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)...

Sortof.  The problem is not that the application protocol _explicitly_
allows TLS re-negotiation in the middle of an application protocol
message.  I bet HTTP has nothing whatsoever to say about that.

The fact that HTTP does allow that folows from the fact that the
application protocol is layered atop TLS.

(I.e., this isn't about HTTP's/HTTPS' authors being bloody stupid.  Lots
of very smart people have been working in these fields without having
noticed this problem.)

> 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,

Necessary, but not sufficient.  You must also drop all prior context.
Alternatively you must bind the new TLS connection to the old, exactly
the proposed fix.  (Note that the proposed fix is even more independent
of application protocol design than the flaw.)

> 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?

The problem is that the HTTP implementation may have no knowledge of
what's going on at the TLS layer[*].  Yes, the HTTP implementation can
tell the TLS layer to re-negotiate, and it can find out what the user's
cert was afterwards.  But if the client initiates [re-]negotiation, the
HTTP server may have no idea that this is happening.  Worse, the TLS
protocol doesn't have any bits on the wire saying that "this is a
re-negotiation", so the client may merely be initiating the first
negotiation even though to the server that looks like a re-negotiation.

In an application protocol with a "starttls" style approach to TLS, this
unawareness of what's going on in the TLS layer can exist, even if it
seems inutitively less likely, but at least such an application protocol
can be constructed so that application messages that can fit in a TLS
record are never fragmented across TLS [re-]negotiations.  Not that
that's enough (see above).

[*] Look at it from a developer's point of view: the TLS API may look
    very similar to read(2) and write(2) system calls.  Applications are
    not normally aware of which reads and writes result in disk I/O (or
    TCP segments, or IP packets, or whatever).  The situation with
    respect to TLS can be quite similar, though just how similar will
    depend on each specific TLS API.