SSL Handshake

SSL uses a combination of public-key encryption and symmetric-key encryption. Symmetric-key encryption is faster than public-key encryption, but public-key encryption provides more effective authentication techniques.

An SSL session always begins with an exchange of messages called an SSL handshake. The SSL handshake allows the server to authenticate itself to the client by using public-key techniques. It then allows the client and server to cooperate in creating symmetric keys that are used for encryption, decryption, and tamper detection during the SSL session that follows. The SSL handshake can also allow the client to authenticate itself to the server.

The following are the types of handshake flows:

• Normal SSL version 3 and TLS version 1 handshake flows
• SSL version 3 and TLS version 1 handshake flows when resuming an SSL session
• SSL version 3 and TLS version 1 handshake flows with client authentication
• SSL Version 2 handshake flows.

For More Information:

• See Client Authentication.
• See Normal Flow.
• See SSL Session Flow.
• See SSL Version 2 Flow.

Normal Flow

The most common SSL handshake (SSL version 3 and TLS version 1 handshake flow for a new session) uses the Rivest-Shamir-Adelman (RSA) key exchange and authenticates the server only; the client is not authenticated. To reduce the number of packets that flow, multiple SSL records can be sent in a single packet. The sequence of commands that occur when messages are exchanged during an SSL handshake are summarized here:

1. The client sends a CLIENT_HELLO command to the server, which includes:
   • The highest SSL and TLS version supported by the client.
   • Ciphers supported by the client. The ciphers are listed in order of preference.
   • Data compression methods that are supported by the client.
   • The session ID. If the client is starting a new SSL session, the session ID is 0.
   • Random data that is generated by the client for use in the key generation process.
2. The server sends a SERVER_HELLO command to the client, which includes:
   • The SSL or TLS version that will be used for the SSL session.
   • The cipher that will be used for the SSL session.
   • Data compression method that will be used for the SSL session. SSL Version 3 and TLS have no compression algorithms defined at this time.
   • The session ID for the SSL session.
   • Random data that is generated by the server for use in the key generation process.
3. The server sends the CERTIFICATE command. This command includes the server's certificate and, optionally, a chain of certificates beginning with the certificate of the certificate authority (CA) that assigned the server's certificate.
4. The server sends the SERVER_DONE command. This command indicates that the server has completed this phase of the SSL handshake. If client authentication will be performed, additional commands flow between the client and the server following the SERVER_DONE command.
5. The client sends the CLIENT_KEY_EXCHANGE command. This command contains the premaster secret that was created by the client and was then encrypted using the server's public key. Both the client and the server generate the symmetric encryption keys on their own using the premaster secret and the random data that is generated from the SERVER_HELLO and CLIENT_HELLO commands.
6. The client sends the CHANGE_CIPHER_SPEC command. This command indicates that the contents of subsequent SSL record data sent by the client during the SSL session will be encrypted. The 5-byte SSL record headers are never encrypted.
7. The client sends the FINISHED command. This command includes a digest of all the SSL handshake commands that have flowed between the client and the server up to this point. This command is sent to validate that none of the commands sent previously, which flow between the client and the server unencrypted, were altered in flight.
8. The server sends the CHANGE_CIPHER_SPEC command. This command indicates that all subsequent data sent by the server during the SSL session will be encrypted.
9. The server sends the FINISHED command. This command includes a digest of all the SSL handshake commands that have flowed between the server and the client up to this point.

The following figure shows the handshake flow for a new session.

Figure 2. Handhake Flow for a New Session

SSL Session Flow

When an SSL session ends cleanly using the SSL_shutdown API and both the client and the server cache the SSL information, it is possible to resume that SSL session at a later time and avoid the expense of encrypting and decrypting the secret master key portions of the SSL handshake.

To resume an SSL session over a new socket, the client includes the session ID of that particular SSL session in the CLIENT_HELLO command that it sends. If the server does not have that session ID in its SSL cache, a new SSL session must be started and the normal SSL handshake flows occur. The server indicates this by creating a new session ID and returning the ID in its SERVER_HELLO command.

If the server does have the requested session ID in its SSL cache, the server echoes that session ID in its SERVER_HELLO command. The client and the server then create new encryption keys based on the cached parameter secret and the new random data from this SSL handshake.

The following figure shows an example of the handshake when resuming an SSL session.

Figure 3. Handshake When Resuming an SSL Session

For More Information:

See Normal Flow.

Client Authentication

When the server requests Client authentication, there are three additional handshake flows (SSL version 3 and TLS version 1 handshake flows with client authentication) to the normal SSL handshake:

1. Before the server sends the SERVER_DONE command, it sends a CERTIFICATE_REQEUST command to request the client certificate. The command contains the names of the certificate authorities (CAs) that the server trusts so that the client can provide a certificate signed by one of those CAs.
2. The client sends a CERTIFICATE command to send its certificate to the server.
3. The client sends a CERTIFICATE_VERIFY command to the server. This command includes a digest of the SSL handshake messages that were signed using the client's private key. The server calculates its own digest and uses the client's public key, which is obtained from the client's certificate, to verify the digest sent by the client.

Figure 4 shows the updated handshake flow.

Figure 4. Handshake Flow with Client Authentication

SSL Version 2 Flow

The SSL version 2 handshake is similar to the SSL version 3 handshake with some slight differences:

1. The client sends a CLIENT_HELLO command. This command includes the ciphers that the client supports, random data that is generated by the client for use in the key generation process, and a session ID if resuming an SSL session.
2. The server sends a SERVER_HELLO command. This command includes a subset of client ciphers that the server supports, the server's certificate, and a connection ID. The connection ID provides the same function as the server random data in SSL version 3 handshake. However, in the SSL version 3 handshake, the server chooses the cipher and sends it to the client while in the SSL version 2 handshake, the client selects the cipher that will be used.
3. The client sends a CLIENT_MASTER_KEY command. This command includes the cipher selected by the client and the master key encrypted with the server's public key.
4. The client sends the CLIENT_FINISHED command. This is the first encrypted message. This command includes the connection ID from the SERVER_HELLO command, which the server checks to verify that the client knows the encryption keys.
5. The server sends a SERVER_VERIFY command. This command contains the encrypted version of the challenge data from the CLIENT_HELLO command, which the client checks to verify that the server knows the encryption keys.
6. The server sends a SERVER_FINISHED command. This command contains the session ID that the client can use to resume the SSL session later on.

Resuming an SSL version 2 session follows the same handshake flow except step 3 is omitted. If the server provides a session ID in the CLIENT_HELLO command and the server has that session ID stored in its cache, the server sets a flag in the SERVER_HELLO command to indicate this.

SSL version 2 allows for client authentication. The server sends a REQUEST_CERTIFICATE command to the client, and the client responds with a CLIENT_CERTIFICATE command.

Figure 5 shows an example of the handshake flow for SSL version 2.

Figure 5. Handshake Flow for SSL Version 2