Cryptography Reference
In-Depth Information
{
perror( “Unable to receive client finished” );
send_alert_message( connection, handshake_failure,
&parameters->active_send_parameters );
return 5;
}
}
// Finally, send server change cipher spec/finished message
if ( !( send_change_cipher_spec( connection, parameters ) ) )
{
perror( “Unable to send client change cipher spec” );
send_alert_message( connection, handshake_failure,
&parameters->active_send_parameters );
return 6;
}
// This message will be encrypted using the newly negotiated keys
if ( !( send_finished( connection, parameters ) ) )
{
perror( “Unable to send client finished” );
send_alert_message( connection, handshake_failure,
&parameters->active_send_parameters );
return 7;
}
// Handshake is complete; now ready to start sending encrypted data
return 0;
}
This listing should be easy to follow if you understood tls_connect (Listing 6-7).
It starts by initializing its own handshake digest pair so that it can validate the
fi nal fi nished message as described in Chapter 6. It also references three new
TLSParameter members that you haven't seen yet:
connection_end : This requires a bit of explanation. Recall from Listing
6-37 that, when calculating keys, the fi rst mac-length bytes were the cli-
ent's MAC secret, and the next mac-length bytes were the server's. If you
want to reuse the same code to compute keys, you must keep track of
whether you are the client or the server, to know which keys to put into
the active_send_parameters and which to put into the active_recv_
parameters . Because tls_accept is only invoked by a TLS server, and
tls_connect is only invoked by a TLS client, it's safe to set this fl ag here
to control common functions.
got_client_hello : Serves the same purpose in tls_accept as got_server_
hello did in tls_connect . Each call to receive_tls_message processes
the next available TLS message, regardless of what type it is — alert,
Search WWH ::




Custom Search