[TLS] Finished verify_data collision (Was Re: draft-turner-ssl-must-not)

[Marsh Ray <[e-mail]>]

On 07/07/2010 10:11 AM, Simon Josefsson wrote:
>
> TLS has integrity-only ciphersuites that does not provide
> confidentiality, making the TLS Finished message visible to attackers.

Yeah I was ignoring that because I was under the impression that it was 
deprecated in TLS 1.2. May be misremembering though.

> But I don't follow the logic here and want to challenge you with a
> question: what attack is enabled if an attacker can find a collision?
> It may help to consider what attacks are enabled if the TLS Finished
> messages is truncated to, say, 10 bits instead.

The attack is if a MitM can convince a client and server that they 
should exchange the same client or server Finished hash, yet the 
handshake has been manipulated by the attacker.

Possible consequences:
* Version downgrade
* Ciphersuite downgrade attack
* Re-establishing unsafe renegotiation with a compatible-mode client and 
a strict server.
* Client credentials stealing/forwarding attack.

The bar is pretty high for this kind of attack:

* It likely needs to be an on-line attack (i.e., attacker has to be able 
to calculate the collision within the timeout window of the handshake. 
One could imagine some systems having no enforced timeout however.

* Mitm needs to obtain the client's premaster secret as part of the 
attack (the key material is needed to generate the hash). Note this is 
trivial with some real clients in common use that don't validate the 
server cert until they receive the Finished message.

* Mitm probably needs to be able to manipulate ~48 bits of data in each 
direction, after any unpredictable values in that direction. For 
example, MitM may inject or manipulate a Certificate Request message in 
the server-to-client direction, this occurs after the unpredictable data 
in the hello and key exchange messages. But an actual cert verify 
message sent in response would mess it up again.

* Probably only a single 96 bit finished message is collide-able. 
Colliding the combined 192 bits may never be practical. Nevertheless, an 
HTTPS server executes a buffered transaction with client cert 
renegotiation on receipt of the single finished message. A client will 
begin transmitting confidential data when he receives the server's 
single Finished message and Mitm may not need the server to accept one 
generated by the client.

I gave this a bunch of thought a while back but couldn't come up with 
anything that could affect a plausible use case of TLS. But the reasons 
why it wouldn't work varied greatly with the negotiated auth mechanism, 
it was not because of any obvious design principle of TLS which resists 
a mitm from engineering a Finished message collision.

With only minor changes, such an attack would be possible. For example, 
if a TLS implementation were to ignore unrecognized handshake messages 
yet included them in the hash.

Consider the case of fixed-parameter DH client-server certificates. I 
don't recall any unpredictable data being sent by either side after the 
random data in the hellos. Mtim could manipulate the server hello as 
seen by the client, inject arbitrary handshake data into an extraneous 
cert presented or cert request received by the client. He might inject 
data into the client key exchange or certificate verify as seen by the 
server, and so on. Mitm could even convince the server to do one type of 
key exchange (e.g., DHE) and the client some other.

Of course, if there is insufficient entropy in the Client Hello random, 
Server Hello random, or the premaster secret then a whole new set of 
possibilities opens up. For example, with a predictable server hello 
random, mitm might be able to modify data as early as the client hello 
in order to engineer a collision in one of the finished messages. It 
might also allow this attack to be partially precomputed offline. (This 
is one reason why I objected so strongly to the idea that a secure TLS 
endpoint could be implemented without a sufficient source of entropy.)

Like I said, there may not be an effective attack here. The use of the 
secret key material in the Finished calculation rules out a lot of 
mischief. But since the "collision insensitivity" of TLS seems to be 
highly dependent on parameters which can be controlled by the attacker, 
we must be extremely careful when extending the handshake, changing 
Finished calculations, or relaxing constraints.

- Marsh