Re: [TLS] simplistic renego protection

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> > The most simplistic approch to renego protection is
> > 
> >    1. the client signals that it is patched through a fake
> >       ciphersuite ID in each ClientHello
> > 
> >    2. the client only supports secure renegotiation and
> >       secure renegotiation is specified to change the definition
> >       of the handshake message hash for renegotiation handshakes
> >       to include the verify_data of the client.finished and
> >       server.finished after the ServerHello.
> 
> No, this does not plug the hole.  The magic ciphersuite in (1)
> requires that the server recognize it, i.e. it is patched.
> Therefore it will not perform insecure renegotiation even
> without seeing the ciphersuite (especially without seeing it).

Of course the server needs to implement secure renegotiation as well.

If the server doesn't want to support old style renegotiation,
it doesn't need to look for the ciphersuite ID at all, it can also
just perform the new handshake message hash for ever renegotiation
handshake.

The fake ciphersuite ID is only for the signaling, and the server
wants to signal back, re-puposing an existing protocol field of a
vanilla ServerHello, then it needs to check whether the client
will get the hint and not choke on it.

> 
> And again the client's INITIAL handshake is the one that the
> server sees as a renegotiation in Marsh's attack, so the fact
> that the client won't REnegotiate (2) is unhelpful; the attack
> has already completed.

Bugs of the server must be fixed at the server.  You can not expect
from end users that they will have every piece of TLS client software
that they might be using reviewed before the dare touching it.


-Martin