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

[David-Sarah Hopwood <[e-mail]>]

David-Sarah Hopwood wrote:
> Martin Rex 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.

The TLS spec doesn't seem to be very clear on whether handshake messages
with an unrecognized HandshakeType must cause an error (section 7.4).
Does anyone know what implementations actually do?

> 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.

Ah, but if the attacker makes ~17.5 million connections (which do not
all have to be to the same site; just to any site that they might want
to attack), then they can expect to get a previous_verify_data that
matches the encoding of a handshake message of unrecognized type.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com