SSL - Handshake

About

This page describes the TLS handshake process.

The TLS handshake process is the first step in a SSL connection where the two parties (client and server):

verifies the identity of each other via certification based authentication
and exchange a symmetric key for further network transfer encryption.

Example

You can see the handshake from a client perspective with openssl. The client and server steps are described below.

Example with the datacadamia website.

openssl s_client -connect datacadamia.com:443 -servername datacadamia.com -state -quiet

SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO ECC Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO ECC Domain Validation Secure Server CA 2
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = sni137003.cloudflaressl.com
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
SSL3 alert read:warning:close notify
SSL3 alert write:warning:close notify

Steps

Standard SSL handshake when RSA key exchange algorithm is used.

During the negotiation between client and server, they will indicate to each other a list of algorithms that can be understood ranked by order of preference. The common preferred algorithm is then chosen.

Client: Hello

Client initiates the request by sending to the server:

Information that the server needs to communicate with the client using SSL. (SSL version number, cipher settings, session-specific data)

For instance, a browser requests a secure page (usually https://).

Server: Hello

The server sends to the client:

its certificate (acquired from a keyStore)
with its corresponding public key
Information that the server needs to communicate with the client using SSL. (SSL version number, cipher settings, session-specific data)

If client authentication is enabled at server side, the server will request a client’s certificate.

If configured, the server may also send the list of Distinguished CA names that it authorizes. This list is then used by the client to select the signed certificate that it must send in its truststore.

If more than one certificate is selected, the client may ask the user to choose one.

Client: Server Authentication and Secret

The client:

authenticates the server certificate (ie checks the certificate)
create a random secret (symmetric encryption key) (with the agreed cipher) (called a pre-master secret for the session)
encrypt the secret using the server public key

The client sends to the server:

the encrypted secret with the encrypted URL required
other encrypted http data.
if client authentication is on, the selected certificate from its keystore and its public key.

Server: Decryption and Master Secret

The Server:

(optionally) authenticate the client certificate against the list of authorized CA’s certificate (if client authentication is on)
decrypts the symmetric encryption key using its private key
uses the symmetric key to decrypt the URL and http data.
sends back the requested document and data encrypted with the symmetric key.

Client: Encryption with Session Key

The client decrypts the data and document using the symmetric key and displays the information.

Both client and server exchange messages to inform that future messages will be encrypted.