Cryptographic Applications - Everyday Cryptography - page 415

Client Request : This message from the client initiates the communication session
and requests the establishment of an SSL-protected channel. As part of this
request message, the client sends some data, including:
•a session ID , which acts as a unique identifier for the session;
• a pseudorandom number r C , which will be used for the provision of freshness;
• a list of cipher suites that the client supports.
Server Response : The server responds by sending some initialisation data,
including:
• the session ID;
• a pseudorandom number r S , which is the server's freshness contribution to the
protocol;
• the particular cipher suite that the server has decided to use (chosen from the
list offered by the client).
• a copy of the server's public-key certificate, including details of any certificate
chain required to verify this certificate.
At this point the client should check that the server's public-key certificate is
valid. This will involve checking the validity of all the public-key certificates in the
chain, as well as checking any relevant CRLs, as discussed in Section 11.3.3.
Pre-master Secret Transfer : The client now generates another pseudorandom
number K P , which it encrypts using the server's public key and sends to the
server. Note that r C and r S are nonces used to provide freshness, hence they are
not encrypted when they are exchanged. In contrast, K P will be used to derive
the keys that are used to secure the session, and hence must be protected when
it is sent over the communication channel. This value K P is referred to as the
pre-master secret and is a value known only by the client and the server. (Note
that it is also possible in SSL to choose to use the Diffie-Hellman protocol to
establish K P .)
The client and server are both now in a position to derive the keys that will be
required to secure the SSL session. The first step in this process is to use a key
derivation function to compute the master secret K M . The key derivation function
uses K P as a key and takes as input, amongst other data, r C and r S . The client and
server both then derive MAC and encryption keys from K M (see our description
of the SSL Record Protocol for details). From this point on, all messages that are
exchanged are cryptographically 'protected'.
Client Finished . The client computes a MAC (the precise details of this process
vary between versions, but most are based on HMAC) on the hash of all the
messages sent thus far. This MAC is then encrypted and sent to the server.
Server Finished . The server checks the MAC received from the client. The server
then computes a MAC on the hash of all the messages that have been sent thus
far. This MAC is then encrypted and sent to the client.