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

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

Martin Rex wrote:
> David-Sarah Hopwood wrote:
>> The old verify_data should not just be appended to the handshake_messages
>> without any further encoding, though, because it might match the bytes
>> of some valid handshake message. In that case, there is the possibility
>> that a MITM might insert the old verify_data into the stream sent to
>> one peer, as though it were a handshake message. If that peer is using
>> the unmodified Finished computation (either because it is unpatched or
>> it is doing an initial handshake), then it may end up computing the same
>> Finished hash as the other peer that is using the modified computation.
>>
>> I haven't gone through the details of this attack thoroughly enough
>> to be sure it will work, but it is too near working for comfort.
> 
> OK.  you got a point!
> 
> It's true that there is a theoretical attack.
> 
> So Mikes idea to always add a length to the hash
> (and therefore also change the initial handshake between
> updated peers) was not so bad after all.
> 
>> 2. Add the old verify_data to handshake_messages preceded by the encoding
>>    of a fatal alert. Then, attacks of the kind described above can't work
>>    because the unpatched peer would first process the alert and abort the
>>    handshake.
> 
> Alerts are no handshake messages, so that doesn't work.

You're right, the attacker could just omit the alert.

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

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.

>   - add something different to both handshake message hashes
>     before adding the verify_data to the renegotiation handshake
>     message hash
>   - frame the Client.Finished.verify_data plus
>     Server.Finished.verify_data as a Finished message
>   - signal initial and renegotiation handshakes differently in the
>     handshake

I'll have to think about these more carefully.

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