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.
-
Log in to the command line of a Linux host (with a current version of OpenSSL) that can access the SSL virtual server.
-
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
-
If the handshake attempt fails, take note of SSL errors returned by the s_client utility.
-
If the handshake succeeds, type the following at the prompt:
GET / HTTP/1.0
-
Press Enter twice.
The HTML page should display.