Re: [TLS] TLS or HTTP issue?

Peter Saint-Andre <stpeter@stpeter.im> Fri, 06 November 2009 16:58 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F94C3A6907 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 08:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.695
X-Spam-Level:
X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=1.905, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1KehT8yNuj7 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 08:58:49 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 683083A6976 for <tls@ietf.org>; Fri, 6 Nov 2009 08:58:49 -0800 (PST)
Received: from squire.local (dsl-175-187.dynamic-dsl.frii.net [216.17.175.187]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5BFB240D09; Fri, 6 Nov 2009 09:59:12 -0700 (MST)
Message-ID: <4AF455DF.5040106@stpeter.im>
Date: Fri, 06 Nov 2009 09:59:11 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org>
In-Reply-To: <4AF33D07.7040100@gnutls.org>
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS or HTTP 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: Fri, 06 Nov 2009 16:58:50 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/5/09 2:00 PM, Nikos Mavrogiannopoulos wrote:
> 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 tend to agree. Some folks in the XMPP community have analyzed the use
of TLS in XMPP, and their preliminary conclusion is that XMPP is not
vulnerable to this attack because the client and server are required to
clear the security context and restart the XML stream after TLS
negotiation (or renegotiation). Those who did this analysis will publish
a brief report about their findings in the near future.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr0Vd8ACgkQNL8k5A2w/vyeqQCgpzZakXwr62UdxAHdNyqwe4xe
WEUAoMPGdY94w+/+oAv9oYC0I9iu7hnI
=sjVM
-----END PGP SIGNATURE-----