Re: [TLS] Could the renegotiation attack be used for session hijacking?

Marsh Ray <marsh@extendedsubset.com> Mon, 09 November 2009 15:17 UTC

Message-ID: <4AF832B1.30309@extendedsubset.com>
Date: Mon, 09 Nov 2009 09:18:09 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>, "tls@ietf.org list" <tls@ietf.org>
References: <34C84617-2B75-4F6D-9F0B-50A528D445C8@checkpoint.com>
In-Reply-To: <34C84617-2B75-4F6D-9F0B-50A528D445C8@checkpoint.com>
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Could the renegotiation attack be used for session hijacking?
Precedence: list

Yoav Nir wrote:
> 
> 1. Client connects without a certificate, but the session is
> authenticated by the protocol (like an HTTP form or FTP login). The MITM
> just proxies the connection to allow the client to authenticate.

TLS is now doing its job providing encryption and MITM cannot read or
modify traffic.

> 2. After a while, the session requires rekeying, so the server sends a
> HelloRequest.

This will be observable by MITM because the record layer does not
encrypt the payload type identifier. It will be seen as a handshake
message from server to client, I believe of predictable size.

> 3. The MITM stops passing data to the client, and sends a ClientHello to
> the server.

The renegotiation handshaking is covered by the encryption state of the
previous session. So this attack is defeated.

It may be that some TLS servers would accept an unencrypted Client Hello
at this point, or even an SSLv2-compatible Client Hello which may be
handled by a different code path. But I don't think those would be bugs
in the TLS protocol, just implementation bugs.

- Marsh

[TLS] Could the renegotiation attack be used for … Yoav Nir
Re: [TLS] Could the renegotiation attack be used … Marsh Ray