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
andFinished
messages from the client before it sends its ownChangeCipherSpec
andFinished
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'sChangeCipherSpec
determine the point in time after which the server only sends encrypted data?