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

[Nicolas Williams <[e-mail]>]

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.

Nico
--