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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Thu, 05 November 2009 21:01 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id E04F73A67DF for <tls@core3.amsl.com>; Thu, 5 Nov 2009 13:01:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id ErFhDlLo1jcX for <tls@core3.amsl.com>; Thu, 5 Nov 2009 13:01:31 -0800 (PST)
Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com []) by core3.amsl.com (Postfix) with ESMTP id ABCD63A67B0 for <tls@ietf.org>; Thu, 5 Nov 2009 13:01:30 -0800 (PST)
Received: by bwz23 with SMTP id 23so451853bwz.29 for <tls@ietf.org>; Thu, 05 Nov 2009 13:01:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=tl2QjYCfeENtfGEdrIWCDPCHnkVHZHNHb2k7QrH3x9Y=; b=JjkpzLc8zVqt1vwZV4JrwwVnfPzy3ybyvgCtWgMDvtnc6sJtDANffOsW6GMEEbk9FN oqzLBa/A/86Wt+pjv/+3JY0WMuIXSq7FvFqnUu8CMvPezGTiJenUiA3EuWbnU8d6wy3j ZmSYL9m5vtGnZUA8TlDG0Vl8Qcu8EvoYCyPrc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=qjXqF+gGgoMR4Wgk9dC2VfnC0zAyHFnluy0YGJXFn9sXQb+Yab+j1VpIEYV45nQ3V6 4wuGlIQW10FTwnu62crK0N/1ol8QyyRnnQMupXxOK1RqEBDx/q0G1cDBHdWEEThDSPTh gp96vzrY7xB4UFk8lb85MeRddqDoRJHiRw0xw=
Received: by with SMTP id l25mr1608332bkw.108.1257454908912; Thu, 05 Nov 2009 13:01:48 -0800 (PST)
Received: from ? (adsl5-183.ath.forthnet.gr []) by mx.google.com with ESMTPS id 21sm2796269fks.39.2009. (version=SSLv3 cipher=RC4-MD5); Thu, 05 Nov 2009 13:00:57 -0800 (PST)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4AF33D07.7040100@gnutls.org>
Date: Thu, 05 Nov 2009 23:00:55 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Thunderbird (X11/20090817)
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com>
In-Reply-To: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com>
X-Enigmail-Version: 0.95.7
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] TLS or HTTP issue? (was: TLS renegotiation issue)
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2009 21:01:32 -0000

Eric Rescorla wrote:
> TLS WG members will want to check out this announcement of a
> new attack on the TLS renegotiation logic. See here:
> http://www.extendedsubset.com/
> The high-level summary is that the attacker negotiates TLS with the
> server and then subsequently proxies the client's negotiation *over*
> that channel. This allows the attacker to inject arbitrary content of
> their choice in front of data sent from the TLS client to the TLS
> server. This data will be treated by the server as if it came from the
> client. Once the new handshake has finished, the attacker can't
> do anything else useful.

 I'll become a bit pedantic and note here that this isn't really a TLS
issue. We have an initial server-authenticated only session and some
renegotiation of parameters over it to authenticate the client. However
TLS doesn't guarantee[0] that if the renegotiation is successful
authenticating the client, then the data from the initial session were
also by the same authenticated client.
 Think for example a session that it is anonymous (DH). Why one should
assume that commands over the anonymous connection are to be trusted if
a successful renegotiation follows?

So for me the issue is on HTTP's usage of the TLS protocol
renegotiation. After a TLS renegotiation for authentication the previous
command cache should have been cleared and reissued after negotiation.

I like the fix in TLS though. As I understand it is a way for the
clients and servers to keep some state between negotiations, which is a
good thing and actually seems to give the guarantee above.


[0]. or is it mentioned somewhere I didn't notice?