Understanding the Change Cipher Spec in a TLS Handshake
In the TLS handshake, the change cipher spec (CCS) plays a crucial role in establishing a secure communication channel between the client and the server. However, the question of who starts with the CCS command often arises.
In SSL 3 through TLS 1.2, if a full handshake is performed, the client sends the CCS after sending the ClientKX (and CertVerify if used), while the server responds with the CCS after receiving the ClientKX (and CertVerify). Therefore, the client is the first to initiate the CCS.
It’s important to note that the type of key exchange protocol, such as [EC]DHE or plain-RSA, does not affect the order of the CCS. The ClientKX exists in both cases, although its content may differ.
In the case of resumption, where an abbreviated handshake is used, the server sends the CCS immediately after the ServerHello, and then the client responds. This can be seen in the TLS 1.2 specification here.
In TLS 1.3, the CCS is not required, but if used, it follows a similar pattern as in the case of resumption. The server sends the CCS after sending the ServerHello but before the EncryptedExtensions, and then the client responds. You can find a combined example of this in the TLS 1.3 documentation here.
Understanding the order of the CCS in a TLS handshake is essential for implementing secure communication protocols and troubleshooting issues that may arise during the handshake process.