B.4 SSL 3.0TLS Handshake

only for RuBoard - do not distribute or recompile

B.4 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.

B.4.1 Sequence of Events

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

The client opens a connection and sends the ClientHello.
The server sends a ServerHello.
[The server sends its certificate.]
[The server sends a ServerKeyExchange.]
[The server sends a CertificateRequest.]
The server sends a ServerHelloDone (TLS only).
[The client sends its certificate.]
The client sends a ClientKeyExchange.
[The client sends a CertificateVerify.]
The client and server both send ChangeCipherSpec messages.
The client and server both send finished messages.
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.

B.4.1.1 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..2¹⁶-1>	A list of the cipher suites that the client supports.
CompressionMethod `compression_methods` <1..2⁸-1>	A list of the compression methods that the client supports.

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

B.4.1.2 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.

B.4.1.3 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.)

B.4.1.4 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 Y_s).
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 Y_c value used in the Fortezza Key Exchange Algorithm (KEA).
opaque `r_c`[128]	The client's R_c 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.^[B]

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

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.

B.4.1.5 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..2⁸-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..2¹⁶-1> [TLS only]	A list of distinguished names of acceptable certificate authorities.

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

This step is performed only for TLS.

B.4.1.7 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.

B.4.1.8 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..2¹⁶-1>	The client's Diffie-Hellman public value (Y_c).
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.

B.4.1.9 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.

B.4.1.10 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.

B.4.1.11 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.

B.4.1.12 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.

only for RuBoard - do not distribute or recompile