According to RFC 5246, 7.1. Change Cipher Spec Protocol:

The ChangeCipherSpec message is sent during the handshake after the security parameters have been agreed upon, but before the verifying Finished message is sent.

And 6.1. Connection States:

A TLS connection state is the operating environment of the TLS Record Protocol. It specifies a compression algorithm, an encryption algorithm, and a MAC algorithm.... All records are processed under the current read and write states. The security parameters for the pending states can be set by the TLS Handshake Protocol, and the ChangeCipherSpec can selectively make either of the pending states current, in which case the appropriate current state is disposed of and replaced with the pending state; the pending state is then reinitialized to an empty state. It is illegal to make a state that has not been initialized with security parameters a current state. The initial current state always specifies that no encryption, compression, or MAC will be used.

ChangeCipherSpec is not covered by the Finished message. From 7.4.9. Finished:

Note: ChangeCipherSpec messages, alerts, and any other record types are not handshake messages and are not included in the hash computations.

Forgive my ignorance, but how exactly is the ChangeCipherSpec authenticated?

1 Answer 1


The ChangeCipherSpec is not authenticated. However, this is not a problem: its contents are unimportant (there is only one kind of ChangeCipherSpec message), and it may appear only at specific moments. When a client or server receives a ChangeCipherSpec message, it actually expects it. Thus, that message does not convey actual information; therefore, it has no need for any protection.

The main purpose of the ChangeCipherSpec message is to force implementations to start a new record. In SSL/TLS, handshake messages are stored in handshake records, but not with a 1-to-1 relationship: a handshake message can be split over several records, and several handshake messages can be stored into a single record. In the conceptual handshake workflow, encryption should be activated right before sending the Finished message; since encryption is record-based, a new record shall be opened. The ChangeCipherSpec message forces that new record, thus making both implementation and specification cleaner.

  • "...Thus, that message does not convey actual information; therefore, it has no need for any protection." - I'm not sure I agree with this (with all due respect). It violates the Horton Principal from Wagner and Schneier's Analysis of the SSL 3.0 Protocol. If a message is sent, it needs privacy or authenticity assurances. If a message does not need privacy or authenticity, then its extraneous and should be removed. However, ChangeCipherSpec seems to have found a home in a third state - needed but not protected.
    – user29925
    Commented Jun 6, 2014 at 19:28
  • Well, you could take the TLS spec, remove ChangeCipherSpec, replacing it with some words like "at this place, switch to the new algorithms and keys". It would still work. The source of the confusion is to consider ChangeCipherSpec as a message: in fact, it is more akin to, say, record headers (which are no more "protected").
    – Tom Leek
    Commented Jun 6, 2014 at 20:02

You must log in to answer this question.