Re: [TLS] Quest for Unified Solution to TLS Renegotiation

[Martin Rex <[e-mail]>]

David-Sarah Hopwood wrote:
> 
> > different possibilities:
> >   - add a bodyless-finished message to the beginning of the handshake
> >     message hash of a secure renegotiation before the ClientHello
> >     a position where the attacker can not insert handshake messages
> 
> It's not clear to me that the attacker can't insert handshake messages
> there. If an implementation normally ignores handshake messages with an
> unrecognized HandshakeType, then it is likely to ignore them before the
> ClientHello as well.

ClientHello is the first handshake message on a connection
that re-initialized the handshake message hash.
If an implementation doesn't get that correct, then it is
an obvious bug of the implementation.

As an additional safety feature, the finished label for
secure renegotiations could be modified.

> 
> For a random 24-byte string, the HandshakeType has a 246 in 256 ~= 96%
> probability of being unrecognized, but then the length is a uint24,
> and the attacker needs it to encode the number 20 in order for the
> attack to work as I described it. So this attack almost certainly isn't
> practical, but we should be sure to prevent it rather than relying on
> probabilities.

I also believe it isn't practical to find a collision with a 24-byte
correctly encoded no-op handshake message (i.e. one that does not
adversly affect the handshake state), but if we can avoid it,
we should avoid it.

verify_data is not predictable, even for those TLS session where
the MitM is an original server or client. 

Thanks for identifying this issue, even when it currently
does not appear as a practical attack.

explicitly inserting the header of a finished message (0x14 0x00 0x00 0x19)
in front of the verify_data might help, because this is something that
an attack does not want to insert after a ServerHello handshake
message (oh yeah, one with an odd length field).


-Martin