Implementation

Handshake Process

A client and a server set up a session using the SSL Handshake Protocol to authenticate the identities of the two parties and negotiate the key and cipher suite. Figure 16-2 shows the SSL handshake process. The Change Cipher Spec message is based on the SSL Change Cipher Spec Protocol, and other messages exchanged in the handshake process are based on the SSL Handshake Protocol, and are SSL handshake messages.

It is optional for an SSL server to authenticate a client's identity. That is, Steps 4, 6, and 8 in Figure 16-2 are optional.

Figure 16-2 SSL handshake process

1. An SSL client sends a Client Hello message to an SSL server to start the handshake process. The Client Hello message carries information about the SSL version and cipher suite supported by the client.
2. The server replies to the client with a Server Hello message, carrying the specified version and cipher suite. If the server allows the client to reuse the session in subsequent communication, the server allocates a session ID for the session.
3. The server sends a digital certificate carrying its public key information to the client, allowing the client to authenticate server identity.
4. (Optional) The server requests that the client provide a certificate, so that the server can authenticate the client identity.
5. The server sends a Server Hello Done message to the client, indicating that the SSL protocol version and cipher suite negotiation finishes and key exchange starts.
6. (Optional) The client sends its certificate to the server.

7. After verifying the validity of the digital certificate of the server, the client responds with a Client Key Exchange message carrying a randomly generated key, which is encrypted using the public key in the server's certificate.

   The randomly generated key, which is called the premaster secret, is used to calculate the symmetric key and MAC key but cannot be used to encrypt data or calculate the MAC value. The client and server use the premaster secret to calculate the same master secret and then use the master secret to calculate the symmetric key and MAC key. Therefore, the premaster secret is of great importance in calculating the symmetric key and MAC key.

8. (Optional) The client sends a Certificate Verify message to the client, so that the server can authenticate the client identity.

   The client computes the hash value using handshake messages and the master secret, encrypts the hash value using its private key, and then sends the hash value to the server through the Certificate Verify message. The server computes the hash value using handshake messages and the master secret, decrypts the received Certificate Verify message using the public key in the client's certificate, and then compares the decrypted value with the hash value. If the two values are the same, the client passes identity authentication.

9. The client sends a Change Cipher Spec message to notify the server that encryption and MAC computation of every subsequent message will be performed based on the key generated using the master secret and cipher suite.

10. The client sends a Finished message to request that the server verify security of the handshake process.

    The client computes a hash value for the exchanged handshake messages, uses the negotiated key and cipher suite to process the hash value (for example, computing, adding MAC, and encrypting the value), and sends a Finished message containing the processed hash value to the server. The server computes a hash value in the same way, decrypts the received Finished message, and compares the two values. If they are the same, MAC verification succeeds and the negotiation of key and cipher suite is successful.

    A hash value is a fixed-length message that is converted from an arbitrary-length message by using a hash algorithm (MD5 or SHA).

11. The server sends a Change Cipher Spec message to notify the client that encryption and MAC computation of every subsequent message will be performed based on the key generated using the master secret and cipher suite.

12. The server sends a Finished message to request that the client verify security of the handshake process.

    The server computes a hash value for the exchanged handshake messages, uses the negotiated key and cipher suite to process the hash value (for example, computing, adding MAC, and encrypting the value), and sends a Finished message containing the processed hash value to the client. The client computes a hash value in the same way, decrypts the received Finished message, and compares the two values. If they are the same, MAC verification succeeds and the negotiation of key and cipher suite is successful.

The SSL client completes authenticating the server identity after the handshake succeeds. Only after the SSL server with a private key decrypts the premaster secret from the Client Key Exchange message, the subsequent handshake process can be successful.

Asymmetric cryptography is used to encrypt keys and authenticate peers during the handshake process between the client and server. The computation consumes considerable system resources. To simplify the SSL handshake process, SSL supports resuming of a negotiated session, as shown in Figure 16-3. The details are as follows:

Figure 16-3 SSL handshake process when session resuming is supported

1. The client sends a Client Hello message. The session ID in this message is set to the ID of the session to be resumed.
2. If the server allows this session to be resumed, it replies with a Server Hello message carrying the same session ID. The client and server can subsequently use the key and cipher suite of the resumed session without additional negotiation.
3. The client sends a Change Cipher Spec message to notify the server that encryption and MAC computation of every subsequent message will be performed based on the key and cipher suite of the original session.
4. The client computes a hash value for the exchanged handshake messages, uses the negotiated key and cipher suite of the original session to process the hash value, and then sends a Finished message to the server so that the server can check whether the key and cipher suite are correct.
5. Similarly, the server sends a Change Cipher Spec message to notify the client that encryption and MAC computation of every subsequent message will be performed based on the key and cipher suite of the original session.
6. The server computes a hash value for the exchanged handshake messages, uses the negotiated key and cipher suite for the original session to process the hash value, and then sends a Finished message to the client so that the client can check whether the key and cipher suite are correct.

Data Transmission Process

The client and server can exchange application layer data after the handshake process completes. Data transmission is implemented using the SSL record protocol during the process.

Figure 16-4 Data transmission process