Re: [TLS] TLS renegotiation issue

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> On Thu, Nov 05, 2009 at 06:11:41PM +0100, Martin Rex wrote:
> > One conceivable approach would be a TLS extension for secure renegotiation
> > with roughly the following semantics:
> > 
> > 
> >  - on initial TLS handshakes (aka Re-nego of a TLS_NULL_WITH_NULL_NULL)
> >    the client that supports secure renegotiation should send the
> >    TLS extension in the client hello with an empty extension data
> >    to signal to the server that it support secure renegotation.
> > 
> >  - 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.

Not a problem.

If it does, that will become obvious in the verification of
the finished messages of the renegotiation handshake.

In addition to the Finished Message verification, such doctoring
will be detected in the ClientVerify verification by the server
when that is a signature over all previous handshake messages
(which is the default).


I'm usually prefer low-impact improvements, which can be added
to existing codebase with ease.  client.random | server.random
from the existing connection seems like a good candidate to me.


-Martin