Re: [TLS] TLS renegotiation issue

[Nicolas Williams <[e-mail]>]

On Thu, Nov 05, 2009 at 11:13:08AM -0600, Nicolas Williams wrote:
> On Thu, Nov 05, 2009 at 06:11:41PM +0100, Martin Rex wrote:
> >  - on TLS session renegotiations, the client should sent the TLS extension
> >    with the extension data containing the client.random and server.random
> >    from the existing session.
> 
> The MITM can make sure they match.
> 
> Why not just send an extension with the tls-unique channel binding for
> the first/outer connection, and then make sure that that gets fed as an
> input for the PRF in the second/inner connection?  I.e., proper channel
> binding.  The MITM _cannot_ make sure that the tls-unique CB of the
> client<->MITM and MITM<->server outer connections match.

I should expand on this.

Suppose you have:

 client <-> MITM <-> server

When the client sends its outer conenction client Hello to the MITM, the
MITM sends one with the same client.random to the server and waits for
the server to send its Hello back, then the MITM sends a Hello back to
the client using the same server.random that the server sent to the
MITM.

The first exchange completes on both sides of the MITM, then the client
sends a request.  The MITM replaces the client's request with whatever
the MITM wants and sends that to the server.  The server requests a
re-negotiation, the MITM passes that on.  When the client and server
re-negotiate they will see that the client.random and server.random from
the outer TLS connection matches.  The MITM wins.

You can't use the client.random and server.random as channel bindings.

But the client's Finished message from the outer TLS connection works.

Suppose the first handshake uses an anonymous DH cipher suite.  The MITM
cannot solve the discrete logarithm problem, therefore the MITM cannot
make sure that the client and server exponentials match for both, the
client<->MITM and MITM<->server connections, therefore the MITM also
cannot cause the Finished messages to match.

Suppose the first handshake uses an RSA key transport key exchange.
This means there must be a server cert.  The MITM cannot make sure that
the server cert seen by the client in its client<->MITM TLS connection
matches that of the real server in the MITM<->server TLS connection
without either possessing the server's private key or breaking RSA.

In all cases, no matter what the TLS key exchange method used, the
Finished messages had better bind the entire handshake and the key
exchange in such a way that no MITM can force the Finished messages to
have any particular value or otherwise match another connection's
Finished messages.  This is central to the security of TLS.  If a MITM
can make the Finished messages for two connections match, then the MITM
must have broken TLS itself.  That's what makes the TLS Finished
messages such a wonderful channel binding for TLS connections.

(In all cases, if the MITM can solve the discrete logarithm problem, has
possession of the server's private key, or can break RSA, you have
bigger problems than a MITM attack.)

Nico
--