How Does the SSL Handshake Secure Your Connection? A Step‑by‑Step Guide

1. SSL Handshake Process

Before encrypted communication can begin, the client and server must first establish a connection and exchange parameters in a procedure called the handshake.

Assuming the client is Alice and the server is Bob, the handshake can be illustrated as follows:

The handshake consists of five steps:

Alice sends the protocol version, a client‑generated random number (Client random), and the list of supported cipher suites.

Bob confirms the cipher suite, sends his digital certificate, and a server‑generated random number (Server random).

Alice verifies the certificate, generates a new random number (Premaster secret), encrypts it with the public key from the certificate, and sends it to Bob.

Bob uses his private key to decrypt the Premaster secret.

Both parties use the three random numbers and the agreed cipher suite to derive the session key, which encrypts the rest of the communication.

2. Role of the Private Key

Three key points to note during the handshake:

Three random numbers are required to generate the session key.

After the handshake, the session is encrypted with the session key (symmetric encryption); the server’s public and private keys are only used to encrypt and decrypt the session key (asymmetric encryption) and have no other purpose.

The server’s public key is embedded in its digital certificate.

This explains why CloudFlare can offer a “Keyless” service: the private key is needed only once to decrypt the session key.

For customers such as banks that use an external CDN but cannot hand over the private key for security reasons, the private key can remain on the origin server, used solely for decrypting the session key while the CDN handles the remaining steps.

In the diagram, the bank’s server participates only in step four; the private key is not used thereafter.

3. DH Algorithm in the Handshake

The entire handshake is transmitted in clear text, so an eavesdropper can see the chosen cipher suite and two of the three random numbers. Security therefore depends on the secrecy of the Premaster secret.

While a sufficiently long RSA public key (e.g., 2048 bits) can protect the Premaster secret, switching to the Diffie‑Hellman (DH) algorithm improves security because the Premaster secret is never transmitted.

With DH, both parties exchange parameters and independently compute the Premaster secret, eliminating the need to send it encrypted.

The diagram shows that steps three and four change from transmitting the Premaster secret to exchanging DH parameters, after which each side computes the secret, enhancing security.

4. Session Resumption

If a connection is interrupted, a new handshake is normally required. Two mechanisms allow the original session to be resumed without a full handshake: session IDs and session tickets.

A session ID is a simple identifier stored by the server. When the client reconnects, it presents the ID; if the server still has the record, both sides reuse the existing session key.

Session IDs are widely supported but are typically stored on a single server, so they cannot be used when requests are load‑balanced across multiple servers.

Session tickets solve this problem. The server encrypts the session state (including the session key and cipher suite) into a ticket and sends it to the client. On reconnection, the client presents the ticket; the server decrypts it and resumes the session without generating a new key.

Only Firefox and Chrome currently support session tickets.

Source: http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html