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?

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

  • That was very helpful, thank you! Out of curiosity, why is an HMAC forgery not enough? Is changing HMAC(master_key, ..., handshake_hash) to HMAC(master_key, ..., handshake_hash') not a forgery? (Of course, it would have to be a "nested forgery", since that hash is authenticated again by the selected SSL MAC, usually also HMAC, using an also unknown key. I can see that the chances of such an elaborate forgery are marginal even for MD5.)
    – lxgr
    Commented Oct 30, 2014 at 15:30
  • The PRF in TLS already uses nested HMAC: you compute a HMAC with, as input, another HMAC value. The "inner" HMAC value is unknown to the attacker. "Normal" forgery analysis uses a model where the attacker has access to a lot of known (or even chosen) message+MAC pairs, and builds a new pair; here, the attacker does not even have such pairs to work with. Commented Oct 30, 2014 at 18:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .