A Usable, Secure Communications Protocol: Client-Side TLS - Implementing SSL/TLS Using Cryptography and PKI - page 345

other side that the key exchange has completed, and every subsequent message
sent by this peer is encrypted and authenticated using it. Note that neither side
should assume that the negotiated parameters are in place before receiving a
change cipher spec message — it's entirely possible that, although a change
cipher spec message is expected, an alert could appear in plaintext instead.
So, at this point in the key exchange, the client should send a change cipher
spec and make its pending send parameters active, but not touch the pending
receive parameters. This is shown in Listing 6-44.
Listing 6-44: “tls.c” send_change_cipher_spec
static int send_change_cipher_spec( int connection, TLSParameters *parameters )
{
char send_buffer[ 1 ];
send_buffer[ 0 ] = 1;
send_message( connection, content_change_cipher_spec, send_buffer, 1 );
memcpy( &parameters->active_send_parameters,
&parameters->pending_send_parameters,
sizeof( ProtectionParameters ) );
init_protection_parameters( &parameters->pending_send_parameters );
return 1;
}
As promised, this is pretty simple. The server then sends a change cipher
spec of its own, and this should be accounted for as in Listing 6-45.
Listing 6-45: “tls.c” receive_tls_msg with support for change cipher spec
...
if ( message.type == content_handshake )
{
...
}
else if ( message.type == content_change_cipher_spec )
{
while ( ( read_pos - decrypted_message ) < decrypted_length )
{
unsigned char change_cipher_spec_type;
read_pos = read_buffer( ( void * ) &change_cipher_spec_type,
( void * ) read_pos, 1 );
if ( change_cipher_spec_type != 1 )
{
printf( “Error - received message ChangeCipherSpec, but type != 1\n” );
exit( 0 );
}
(Continued)