Re: [TLS] TLS renegotiation issue

Florian Weimer <> Thu, 05 November 2009 18:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD0EC28C110 for <>; Thu, 5 Nov 2009 10:40:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6XtItV+RDbe3 for <>; Thu, 5 Nov 2009 10:40:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 90A533A69F0 for <>; Thu, 5 Nov 2009 10:40:01 -0800 (PST)
Received: from ([]) by with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1N67Ft-0006lZ-KC; Thu, 05 Nov 2009 19:40:21 +0100
Received: by with local id 1N67Ft-0002CR-Gw; Thu, 05 Nov 2009 18:40:21 +0000
To: Eric Rescorla <>
References: <> <>
From: Florian Weimer <>
Date: Thu, 05 Nov 2009 18:40:21 +0000
In-Reply-To: <> (Eric Rescorla's message of "Thu\, 5 Nov 2009 10\:16\:11 -0800")
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [TLS] 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: Thu, 05 Nov 2009 18:40:02 -0000

* Eric Rescorla:

> I now have a draft extension up at:
> Comments welcome.

Most email addresses are incorrect. 8-)

Based on the attack description in the draft, the server can implement
a layering violation and detect a splicing which crosses an
application-layer record boundary (which should result in a hard
error).  If the splicing does not cross a boundary, there is not
really any ambiguity, just a succession of differently authenticated
application records.

What seems to happen in vulnerable applications I've created in a
previous life (but I have no longer access to them, so I can't check
for sure) is that in a HTTP context, you tend to perform a sub-request
within the server to get the authentication information which only
applies to future requests, and use that to answer the
not-really-authenticated request as if it were authenticated.  As a
result, you're still vulnerable even if you refuse to renegotiation in
the middle of an HTTP request message.

So avoiding protocol changes seems to require an API change (to expose
part of the TLS record layer to the application layer, so that
byte-exact authentication information is available) plus extensive
application code changes, potentially resulting in additional
client/server round-trips.

Therefore, I think a protocol change is less invasive (assuming that
it is essentially free-for-all-uses IPR-wise).

Florian Weimer                <>
BFK edv-consulting GmbH
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99