Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

RFC 2246 says:

To help avoid pipeline stalls, ChangeCipherSpec is an independent TLS Protocol content type, and is not actually a TLS handshake message.

What pipeline stalss is being spoken about here? Why didn't the creators of TLS make Change Cipher Spec a part of Handshake Message itself?

share|improve this question
up vote 13 down vote accepted

SSL uses messages which are encoded over records. Encryption is done on a per record basis. However, several messages of the same type (e.g. handshake messages) can be crammed together in the same record. Since the Change Cipher Spec message modifies encryption settings, a new record should begin immediately afterwards, so that the new settings are immediately applied (in particular, it is crucial for security that the Finished message uses the new encryption and MAC).

Using a specific record type for Change Cipher Spec is a way to enforce this property. An SSL/TLS implementation cannot help but begin a new record for the Finished message, since it uses a record type distinct from that of the Change Cipher Spec message. Such a specific record type could be avoided if all SSL/TLS implementations were disciplined enough to begin a new record where they need, and also to verify that the peer also began a new record. It is safer and more robust to make it unavoidable through the record type.

share|improve this answer
    
so this is to prevent bad implementations or a design problem? if I understand correctly: without the changecipherspec, tls by design would cram the finished message with client key exchange and other client messages? – David 天宇 Wong Jan 15 at 17:43
1  
The ChangeCipherSpec message is mostly historical. One could design a protocol which looks like SSL/TLS but without that specific message, and it would work because when a party sends a ChangeCipherSpec, the peer expects it (and will complain if the message is not received). From a protocol point of view, the message is redundant. However, presence of that message makes it more difficult for bad implementers to make a bad implementation in that respect. – Thomas Pornin Jan 15 at 18:22

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.