SSL 3.0/TLS Handshake

When a client connects to an SSL or TLS server, the SSL/TLS Handshake begins. The Handshake establishes the protocols that will be used during the communication, selects the cryptographic algorithms, authenticates the parties, and uses public key cryptography to create a master secret , from which encryption and authentication keys are derived.

The master secret for the session is created by the server using a premaster secret sent from the client.

The master secret is used to generate four more secrets (keys):

• An encryption key used for sending data from the client to the server.

• An encryption key used for sending data from the server to the client.

• An authentication key used for sending data from the client to the server.

• An authentication key used for sending data from the server to the client.

Sequence of Events

The Handshake is performed by a complex exchange between the client and the server. Optional items are indicated in brackets:

1. The client opens a connection and sends the ClientHello.

2. The server sends a ServerHello.

3. [The server sends its certificate.]

4. [The server sends a ServerKeyExchange.]

5. [The server sends a CertificateRequest.]

6. The server sends a ServerHelloDone (TLS only).

7. [The client sends its certificate.]

8. The client sends a ClientKeyExchange.

9. [The client sends a CertificateVerify.]

10. The client and server both send ChangeCipherSpec messages.

11. The client and server both send finished messages.

12. Application data flows.

With the exception of the secrets that are encrypted with the recipient’s public key, the entire Handshake is sent unencrypted, in the clear. The secrets are then used to encrypt all subsequent communications.

1. ClientHello

The SSL/TLS ClientHello is a message that contains the information shown in Table B-1.

Table B-1. ClientHello message

Field	Meaning
ProtocolVersion client_version	The highest SSL/TLS version understood by the client. 3.0 for SSL 3.0; 3.1 for TLS 1.0.
Random random	A random structure (consisting of a 32-bit timestamp and 28 bytes generated by a secure random number generator).
SessionID session_id	The session ID. Normally, this is empty to request a new session. A nonempty session ID field implies that the client is attempting to continue a previous SSL session. The client can specify 0 to force a new session for security reasons.
CipherSuite cipher_suites<2..216-1>	A list of the cipher suites that the client supports.
CompressionMethod compression_methods <1..28-1>	A list of the compression methods that the client supports.

After the client sends the ClientHello, it waits for the ServerHello message.

2. ServerHello

When the SSL/TLS server receives the ClientHello, it responds with either a handshake_failure alert or a ServerHello message.

The ServerHello message has the form shown in Table B-2.

Table B-2. ServerHello message

Field	Meaning
ProtocolVersion client_version	The SSL version used by the client (3.0).
Random random	A random structure (consisting of a 32-bit timestamp and 28 bytes generated by a secure random number generator).
SessionID session_id	The session ID. The server may return an empty session_id to indicate that the session will not be cached and therefore cannot be resumed. If it matches the session_id provided by the client in the ClientHello, it indicates that the previous session will be resumed. Otherwise, the session_id of the new session is provided.
CipherSuite cipher_suite	The cipher chosen by the server for this session.
CompressionMethod compression_method	The compression method chosen by the server for this session.

Notice that the server chooses the cipher suite and compression method to be used for the SSL/TLS connection. If the server does not implement or will not use any of the cipher suites and compression methods offered by the client, the server can simply send a handshake_failure alert and terminate the session.

3. Server certificate

After sending the ServerHello, the server may optionally send its certificate. The certificate consists of one or more X.509 v1, v2, or v3 certificates. (If the server uses the Fortezza cipher suite, the server certificate sent is a modified X.509 certificate.)

4. Server key exchange

The server sends the server key exchange message if the server has no certificate or if it has a certificate that is used only for signing. This might happen in one of three cases:

• The server is using the Diffie-Hellman key exchange protocol.

• The server is using RSA, but has a signature-only RSA key.

• The server is using the Fortezza/DMS encryption suite.

The key exchange message consists of the fields shown in Table B-3.

Table B-3. Server key exchange parameters

Field	Meaning
For Diffie-Hellman key exchange:
ServerDHParams params	The server’s Diffie-Hellman public value for p, g, and Ys (SSL only sends Ys).
For RSA:
ProtocolVersion client_version	The most recent version of the SSL protocol supported by the client.
opaque random[46] (encrypted with server’s RSA public key)	46 random bytes generated with a secure random number generator.
For Fortezza/DMS (not supported by TLS)
opaque y_c<0..128>	The client’s Yc value used in the Fortezza Key Exchange Algorithm (KEA).
opaque r_c[128]	The client’s Rc value used in the KEA.
opaque wrapped_client_write_key[12]	The client’s write key, wrapped by the Fortezza’s token encryption key (TEK).
opaque wrapped_server_write_key[12]	The server’s write key, wrapped by the Fortezza’s TEK.
opaque client_write_IV[24]	The initialization vector (IV) for the client write key.
opaque server_write_IV[24]	The IV for the server write key.
opaque master_secret_IV[24]	The IV for the TEK used to encrypt the premaster secret.
block-ciphered opaque encrypted_pre_mater_secret[48]	48 bytes generated with a secure random number generator and encrypted using the TEK.

Signatures may be RSA signatures, DSA signatures, or anonymous (in which case there are no signatures). Servers that have no signatures offer no protection against man-in-the-middle or server substitution attacks.^[230]

SSL 3.0 and TLS define three modes of Diffie-Hellman operations for the initial key exchange:

Anonymous Diffie-Hellman

In this mode, the server generates its Diffie-Hellman public value and the Diffie-Hellman parameters and sends them to the client. The client then sends back its client value. This mode is susceptible to the man-in-the-middle attack, because the server’s parameters and public value are not authenticated. (In a man-in-the-middle attack, an attacker could simply conduct anonymous Diffie-Hellman with both parties.)

Fixed Diffie-Hellman

In this mode, the server’s certificate contains its fixed Diffie-Hellman parameters instead of an RSA or DSS public key. Because SSL 3.0 allows only one key per server, a server that is configured to operate in fixed Diffie-Hellman mode cannot interoperate with SSL clients that expect to perform RSA key exchanges.

Ephemeral Diffie-Hellman

In this mode, the server generates its own Diffie-Hellman parameters, then uses a pre-existing RSA or DSS public key to sign the parameters, which are then sent to the client. This third mode appears to be the most secure SSL 3.0 operating mode.

Few commercial products implement the Diffie-Hellman SSL/TLS key exchange algorithms.

5. Certificate Request

If the server wishes to authenticate the client, it can send a Certificate Request to the client. Certificate Requests consist of five parts, shown in Table B-4.

Table B-4. Certificate Request message

Field	Meaning
ClientCertificateType certificate_types <1..28-1>	The types of certificates requested by the server.
Random random [SSL only]	A random structure (consisting of a 32-bit timestamp and 28 bytes generated by a secure random number generator).
SessionID session_id [SSL only]	The session ID. This field is never empty. If it matches the session_id provided by the client in the ClientHello, it indicates that the previous SSL session will be resumed. Otherwise, the session_id of the new session is provided.
CipherSuite cipher [SSL only]	The cipher chosen by the server for this session.
CompressionMethod compression_method [SSL only]	The compression method chosen by the server for this session.
DistinguishedName certificate_authorities <3..216-1> [TLS only]	A list of distinguished names of acceptable certificate authorities.

6. The server sends a ServerHelloDone (TLS only)

This step is performed only for TLS.

7. Client sends certificate

If requested by the server, the client sends any certificates that were requested. If no certificate is available, the client sends the no certificate alert.

It is up to the server to decide what to do if a no certificate alert is received. The server could continue the transaction with an anonymous client. Alternatively, the server could terminate the connection by sending a data handshake failure alert.

8. ClientKeyExchange

The client can send one of three kinds of key exchange messages, depending on the particular public key algorithm that has been selected. These are shown in Table B-5.

Table B-5. Server key exchange parameters

Field	Meaning
For Diffie-Hellman key exchange:
opaque dh_Yc<1..216-1>	The client’s Diffie-Hellman public value (Yc).
Signature signed_params	The signature for the parameters.
For RSA:
ServerRSAarams params	The server’s RSA parameters.
Structure signed_params	The signature for the parameters.
For Fortezza/DMS [SSL only]:
ServerFortezzaParams params	The server’s Fortezza parameters.

9. CertificateVerify

If the client sends a public certificate that has signing capability (such as an RSA or a DSS certificate), the client now sends a CertificateVerify message. This message consists of two message authentication codes, one calculated with the MD5 algorithm and one calculated with SHA. They are:

CertificateVerify.signature.md5_hash
            MD5(ClientHello.random + ServerHello.random + ServerParams);

CertificateVerify.signature.sha_hash
            SHA(ClientHello.random + ServerHello.random + ServerParams);

The handshake_messages refers to all handshake messages starting with the ClientHello up to but not including the CertificateVerify message.

10. ChangeCipherSpec

After the CertificateVerify is sent, the ChangeCipherSpec message is sent. After the message is sent, all following messages are encrypted according to the specified cipher suite and compressed according to the compression method.

11. Finished

Finally, both the client and the server send finished messages. The finished message consists of the result of a pseudorandom function (another hash) that takes as arguments the master secret, the finished_label , and both the MD5 and SHA-1 of the handshake message.

The finished message verifies that both the client and server are in proper synchronization. If they aren’t, then the SSL link is terminated.

12. Application Data

After the finished message is sent, application data is transported. All application data is divided into individual record-layer messages. These messages are then compressed and encrypted according to the current compression method and cipher suite.

---

^[230] A server substitution attack is an attack in which somebody replaces your server with theirs.