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

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Nov 2009 14:59:27 +0200

Hi.

One of our security experts came up with an extension to the  
renegotiation attack, that may lead to session hijacking. It's  
probably not relevant for HTTPS, because those connections are short- 
lived, but may be relevant for applications with longer-lived sessions  
that require rekeying. draft-rescorla-tls-renegotiation should solve  
this as well:

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.

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

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

4. The server and MITM complete the handshake, and the MITM has  
effectively hijacked the session from the client. The persistent  
application session means that the MITM is now authenticated to the  
server as the client.

Seems to me that this will work, right?  Am I missing something?

Yoav

---

From: Marsh Ray <[email-masked]>
Date: Mon, 09 Nov 2009 09:18:09 -0600

Yoav Nir wrote:
> 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

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