Apparently, in the past, a man in the middle was able to defeat the security (confidentiality, to be precise) of TLS by simply suppressing the ChangeCipherSpec message.

It's called "ChangeCipherSpec Drop" and unfortunately, I was only able to find very little information about it online.

Some sources said the attacker would simply drop the ChangeCipherSpec message, others were less precise about it, and this graphic I found here shows both the ChangeCipherSpec and the Finished message crossed through.

My questions are:

  • Why did the server then send payload data? Isn't the server supposed to wait until having received the ChangeCipherSpec and Finished messages from the client before it sends its own ChangeCipherSpec and Finished messages and only send payload data after that?
  • How is this even triggered? There expectedly has to pass time between the server's last message of the first half of the connection establishment (ServerHelloDone) and the server's first message of the second half of the connection establishment. An entire round-trip time, even. How the server doesn't just start sending payload data right away every time. Is there a really weird timeout?
  • How did the client's ChangeCipherSpec not arriving cause the server to send its payload data unencrypted? Shouldn't the server's ChangeCipherSpec determine the point in time after which the server only sends encrypted data?

1 Answer 1


The attack is described in Analysis of the SSL 3.0 protocol from David Wagner and Bruce Schneier in section "4.3 Dropping the change cipher spec message". In short:

  • The attack works by stripping the ChangeCipherSpec message (but not the Finished message). This works since the (existence and content of the) ChangeCipherSpec message is not protected by the MAC in the Finished message.
  • The attack works only when a cipher is used which provides no or only very weak encryption, i.e. the encryption of the Finished message must be none or weak enough to break it in real time.
  • The language in TLS 1.0 makes it more clear that there should be no Finished message without preceding ChangeCipherSpec.

For more details see the paper.

You must log in to answer this question.

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