SSL Handshake Overview

Reference : https://support.f5.com/csp/article/K15292

SSL Handshake Overview

SSL communication consists of a series of messages exchanged between two parties (client and server). The SSL handshake between a client and server consists of nine steps, and appears as follows.

The SSL messages determine the parameters of the encrypted communication channel that the two parties will use. It is important that the client and server agree on the message details, such as the protocol version, cipher suites, secure renegotiation, or client certificate requests. Otherwise the handshake will fail. The SSL handshake has the following messaging components:

ClientHello

When a client first attempts to connect to an SSL server, it initiates the session by sending a ClientHello message to the server. The ClientHello message starts the SSL communication between the two systems. The ClientHello message contains some of the following components:

• Version: The version field contains the highest SSL version that the client supports.
• Random: A random number generated by the client.
• Session ID: An arbitrary sequence of bytes chosen by the server; it identifies a particular SSL session. The client may attempt to resume a previously established session by sending a non-zero session ID.
• Cipher suites: Identifies the list of ciphers suites that the client supports.
• Compression: Identifies the list of compression methods that the client supports.

ServerHello

If the server is able to find an acceptable set of algorithms, it responds to the ClientHello message with a ServerHello message. The server may use the ServerHello message to allow a resumed session. The ServerHello message contains some of the following components:

• Version: The version field contains the highest SSL version supported by both the client and server.
• Random: A random number generated by the server.
• Session ID: Identifies a particular SSL session. If the client sends a non-zero session ID and the server locates a match in its cache, the server will attempt to respond with the same value as was supplied by the client, and resume the session using the same cipher suite.
• Cipher suites: Identifies the cipher suite chosen by the server from the list of ciphers that the client supports.
• Compression: Identifies the compression method chosen by the server from the list that the client supports.

Certificate

The server sends its Certificate message containing the server's certificate or list of (chain) certificates, depending on the selected cipher suite.

Note: The server may send a ServerKeyExchange message when the server Certificate message does not contain enough data to allow the client to exchange a premaster secret. This is true of some ciphers such as DHE-DSS.

ServerHelloDone

After sending its certificate, the server sends a ServerHelloDone message, indicating it is done with handshake negotiation.

ClientKeyExchange

The client sends the ClientKeyExchange message containing the PreMasterSecret. The PreMasterSecret is sent encrypted using the public key of the server.

ChangeCipherSpec

Both the client and server send the ChangeCipherSpec message after the security parameters have been determined. The ChangeCipherSpec message activates the negotiated SSL options for the session. From this point forward, all messages are authenticated and encrypted. This stage is significant as it indicates that subsequent records will be protected under the newly negotiated CipherSpec and keys.

Finished

Each party sends a Finished message under the new algorithm, keys and secrets. The Finished message indicates that the handshake is complete, and the parties may begin to exchange application layer data.

Resumed SSL sessions

A resumed SSL session implements session identifier (session ID) to re-establish a previously negotiated session. When an SSL handshake is resumed, the client presents the session ID from the previously negotiated session. If the server finds the session ID in its cache and accepts the resumed session, it sends back the same session ID and the parties skip the public key operation. If the server does not accept the resumed session, it issues a new session ID and implements the full SSL handshake. The resumed SSL handshake between a client and server consists of the following steps.

  

 

Testing SSL connections (using s_client)

After you enable SSL debug logging on the BIG-IP system, you should test SSL connections for the virtual server using a web browser or other utility, such as the OpenSSL utility, s_client, or cURL. Using the s_client utility may provide additional debugging information that you can use to troubleshoot the issue. After making several requests to the virtual server, you can review and analyze the debug log files on the BIG-IP system.

Impact of procedure: Performing the following procedure should not have a negative impact on your system.

1. Log in to the command line of a Linux host (with a current version of OpenSSL) that can access the SSL virtual server.
   
2. To test SSL connections for the virtual server, use the following command syntax:
   
   openssl s_client -connect <virtual_server>:<port> -msg
   
   For example:
   

   openssl s_client -connect 10.12.23.115:443 -msg
   openssl s_client -connect https://<url_of_website> -msg

3. If the handshake attempt fails, take note of SSL errors returned by the s_client utility.
   
4. If the handshake succeeds, type the following at the prompt:
   
   GET / HTTP/1.0
   
5. Press Enter twice.
   
   The HTML page should display.