The SSL and TLS protocols enable two parties to identify and authenticate each other and communicate with confidentiality and data integrity. The SSL and TLS protocols provide communications security over the internet and allow client/server applications to communicate in a way that is confidential and reliable.
The protocols have two layers: a Record Protocol and a Handshake Protocol, and these are layered above a transport protocol such as TCP/IP. They both use asymmetric and symmetric cryptography techniques.
An SSL or TLS connection is initiated by an application, which becomes the SSL or TLS client. The application which receives the connection becomes the SSL or TLS server. Every new session begins with a handshake, as defined by the SSL or TLS protocols.
SSL/TLS 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 handshake has the following messaging components:
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.
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.
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.
4. ServerHelloDone :
After sending its certificate, the server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
The client sends the ClientKeyExchange message containing the PreMasterSecret. The PreMasterSecret is sent encrypted using the public key of the server.
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.
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.
Steps 8 and 9: ChangeCipherSpec and finished will be performed the same way as in server mentioned above.
Example of Successful SSL handshake,
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:
Identifying SSL handshake failures
When troubleshooting SSL handshake failures, it is important to identify the stage in which the failure occurs. For example, if the failure occurs during the initial negotiation phase, the client and server may not have agreed on the complete list of parameters, such as protocol version or cipher. For information about identifying handshake failures, refer to the following information:
Impact of procedure: Performing the following procedure should not have a negative impact on your system.
During the negotiation phase, the client starts the SSL communication between the two systems by presenting the SSL options to the server, and the server responds by selecting the options it supports. This stage defines the parameters for the secure channel. If the client and server do not agree on the complete list of options, the handshake will fail, often with very little diagnostic data. The most common failures during the negotiation stage involve the following incompatible components: protocols, ciphers, secure renegotiation options, or client certificate requests.
To understand failures in the negotiation stage, it is important to understand the client and server behavior during the message exchange.
- The ClientHello offers the highest protocol version supported by the client. If the server does not support the client's protocol version, the server responds with a lower protocol version. The client then decides whether to downgrade the protocol or abort the SSL handshake.
- The ClientHello also offers a list of supported cipher suites, in the preferred order. The server then typically chooses the highest cipher level shared by both. If the server does not support the ciphers from the client's list, the handshake will fail.
Negotiation phase handshake examples
In the following example, the client offered protocol TLSv1.2 (version 3.3) and the server downgraded the protocol to TLSv1.0 (version 3.1). The server also chose the preferred cipher from the client's list:
1 1 0.0003 (0.0003) C>SV3.3(79) Handshake
ClientHello: Version 3.3
1 2 0.0008 (0.0005) S>CV3.1(74) Handshake
ServerHello: Version 3.1
cipherSuite : TLS_RSA_WITH_RC4_128_SHA
In the following examples, the client and server fail to agree on the SSL protocol version in the first example, and the SSL cipher in the second example.
Example 1: The client and server unsuccessfully negotiate the protocol. The server does not support protocol version below TLS1 (version 3.1) and the client does not support protocol versions above SSLv3 (version 3.0):
1 1 0.0012 (0.0012) C>SV3.0(47) Handshake
ClientHello: Version 3.0
1 2 0.0013 (0.0000) S>CV0.0(2) Alert
Example 2: The client and server unsuccessfully negotiate a cipher; the server does not support any of the client's ciphers. This is a common failure:
1 1 0.0012 (0.0012) C>SV3.1(58) Handshake
ClientHello: Version 3.2
1 2 0.0013 (0.0000) S>CV3.2(2) Alert
Note: The SSL alert message (Alert 2 level fatal) is marginally useful and means an unrecoverable error has occurred. If the virtual server is using a Client SSL profile, you may be able to enable useful message logging by modifying the SSL logging level to debug.
Authored By - Susin Kumar
TCS Cyber Security Community