Cryptography Reference
In-Depth Information
{
perror( “Unable to receive client finished” );
send_alert_message( connection, handshake_failure,
¶meters->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,
¶meters->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,
¶meters->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