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?