How well is the SSL/TLS handshake protected against modifications?

Question

The SSL/TLS handshake is protected against downgrade attempts by the Finished message, a signed and authenticated hash of the master secret and all previous handshake messages.

Consider a client that uses a mix of strong and weak cipher suites that connects to a server that supports the same set of ciphers. Usually, one or both parties will prefer a strong cipher, and the connection will be securely established.

What capabilities would an attacker need to have in order to actively downgrade the handshake to one of the weak cipher suites? I'm assuming that the master key establishment via RSA or (EC)DH can't be broken by the attacker.

I think they have to be able to do at least the following:

• Compute a valid hash value for the modified handshake (e.g. with some cipher suites removed or changed to invalid values), without knowing the master secret, and possibly also without knowing the original hash value (depending on the encryption scheme used)
• Perform those hash modifications to ciphertexts (with unknown plaintexts), since the Finished message is encrypted
• Modify the encrypted authentication tag for the Finished message (since SSL/TLS use authenticate-then-encrypt) so that it is valid for the modified handshake hash, again without knowing the original value.

"How broken" does a hash function, "how malleable" does a cipher have to be to enable such an attack? Is there any chance today or in the forseeable future (considering the existing attacks on MD5, SHA1, RC4 etc.) of an attack becoming possible for one of the existing legacy cipher suites, except for maybe the export versions where the master key might be brute-forced by the attacker?

Or is it safe to leave those "moderately secure" cipher suites enabled in client and rely on the handshake protection?

Answer 1

In "hash" of the handshake messages, as used in the Finished messages, is computed with the PRF, which uses the master secret as additional parameter (in SSL 3.0 the computation is different but the master secret is still used; the 36-byte values are sort-of-HMAC with both MD5 and SHA-1). If the attacker alters one of the previous handshake messages, then he must be able to fix the first Finished message accordingly. That message is the first one that gets encrypted.

The consequence is that even if the encryption system is awfully weak, the attacker must be able to break it with no known plaintext whatsoever if he wants to simply learn the Finished message contents. This must be an online break, meaning that any failure on his part implies impossibility to complete the handshake. As such, even 40-bit encryption would be highly effective at thwarting such attacks.

Let's suppose nonetheless that for some reason, the encryption layer is completely transparent to the attacker (e.g. the cipher suite is TLS_RSA_WITH_NULL_SHA, with no encryption at all). Our attacker still faces two formidable challenges:

1. The MAC is HMAC (or sort-of-HMAC in the case of SSL 3.0), for which there is no known attack, even when using MD5 as base function (see this, and then that). To make a baseline, there is a known forgery attack on HMAC with MD4, but even that one is still very expensive and thus theoretical only.

2. The PRF itself is based on a lot of HMAC, so the attacker will have a hard time computing his modified Finished. Mere forgery attacks on HMAC would not be enough; he would have to be able to recover the key (the master secret).

Notably, in TLS, the Finished messages have length 12 bytes (36 bytes for SSL 3.0), while the master secret has length 48 bytes. This means that it is mathematically impossible to recover the complete master secret from the first Finished message, however weak the PRF may be.

To be able to break the handshake integrity, we have to assume a very weird interaction of the PRF with itself, since the PRF is used to compute both the encryption and MAC keys that are applied to the PRF-generated Finished contents. This looks implausible. Alternatively, break through the key exchange mechanism itself. The key exchange (RSA, DH...) looks like the only non-ridiculous attack path (as far as we know).