Just curious how this one works in practice and if it's as much of a risk as has been made out? It says you actively require a MiTM scenario, which is understandable, but then what are the steps to actually downgrade the cipher spec?

As a MiTM, if you try and alter the messages between client/server (ie to downgrade the CipherSpec), surely due to the nature of SSL the client would get a notification that the messages aren't from the intended source?

Or does the attacker change the CipherSpec of a client/server for all connections and simply sniff the traffic between them?

Or do you need to combine this with another SSL vulnerability to trick the client into thinking you are the source and therefore it can trust messages between you?

  • 1
    See also security.stackexchange.com/q/60763/13154. Duplicate? Commented Jul 3, 2014 at 9:47
  • I considered adding to that discussion, but I wouldn't consider my question a duplicate as it talks more about how this vulnerability works from a technical level
    – TimC
    Commented Jul 3, 2014 at 9:49
  • I think that Q does answer your question, though briefly. AIUI (from discussion on the openssl maillist, not actually following the code) it doesn't downgrade the cipher the way you stated, instead it 'downgrades' the key by getting openssl to do the correct KDF on incorrect input: only the nonsecret nonces, but not the premaster secret as per spec. The attacker can re-do the KDF and get the session keys, and then Bob and Alice are your uncle and aunt as it were. Commented Jul 3, 2014 at 10:41

1 Answer 1


The idea of this attack is that it is taking place in the SSL handshake, hence the client is still not aware of the MITM and since the attack manages to downgrade the key of the encryption it will manage to make your client believe it is talking to the real server. So if someone manages to MITM your client with the client and server both using open ssl with the vulnerable versions its game over.

This blog post has a nice explanation and insite into the bug: https://www.imperialviolet.org/2014/06/05/earlyccs.html

  • Thank you, that explains it! So rather than waiting for a full SSL session to be established, the MiTM would wait to see the handshake, insert a message at the appropriate point to ChangeCipherSpec to something easy to crack, then can sit and capture the traffic knowing it can be decrypted later. Makes sense now!
    – TimC
    Commented Jul 3, 2014 at 11:16

You must log in to answer this question.

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