How SSL/TLS Secures Internet Communication: Mechanisms and Handshake Explained

Internet communication security is built on the SSL/TLS protocol.

Purpose

SSL/TLS was designed to eliminate three major risks of unencrypted HTTP communication:

Eavesdropping risk : third parties can read the transmitted data.

Tampering risk : third parties can modify the data.

Impersonation risk : third parties can pretend to be the other party.

The protocol aims to ensure that all information is encrypted, that any alteration is detectable, and that identity certificates prevent impersonation.

History

1994 – Netscape designs SSL 1.0 (unreleased).

1995 – SSL 2.0 released, quickly found to have serious flaws.

1996 – SSL 3.0 launched and widely adopted.

1999 – IETF takes over, releases TLS 1.0 as an upgrade to SSL.

2006 & 2008 – TLS 1.1 and TLS 1.2 are introduced.

2011 – Revision of TLS 1.2.

Today TLS 1.2 is supported by all major browsers, while TLS 1.0 (often labeled SSL 3.1) remains the most deployed version.

Basic Operation Process

The core idea is to use public‑key encryption to exchange a symmetric session key. The client requests the server’s public key, encrypts data with it, and the server decrypts with its private key.

Two challenges arise:

How to ensure the public key is not tampered with? The solution is to embed the public key in a trusted digital certificate.

Public‑key encryption is computationally heavy. The solution is to generate a temporary “session key” for each conversation; the session key is symmetric (fast), while the server’s public key only encrypts the session key itself.

The basic steps are:

Client requests and verifies the server’s public key.

Both sides negotiate and generate a session key.

Both sides use the session key for encrypted communication.

The first two steps constitute the “handshake phase”.

Handshake Process

The handshake consists of four clear‑text messages.

4.1 ClientHello

The client (usually a browser) sends a ClientHello containing:

Supported protocol version (e.g., TLS 1.0).

A client‑generated random number for later session‑key derivation.

Supported cipher suites (e.g., RSA).

Supported compression methods.

Originally the client did not send the server’s domain name, limiting a server to a single certificate; the Server Name Indication (SNI) extension added in 2006 solves this.

4.2 ServerHello

The server replies with ServerHello, providing:

Chosen protocol version.

A server‑generated random number.

Chosen cipher suite.

The server’s certificate.

If client authentication is required, the server also requests a client certificate.

4.3 Client Response

The client validates the server’s certificate. If valid, it extracts the server’s public key and sends:

A random number encrypted with the server’s public key (the “pre‑master secret”).

A ChangeCipherSpec message indicating that subsequent messages will be encrypted.

Finished message containing a hash of all previous handshake data for verification.

These three random values (client random, server random, pre‑master secret) are combined by both sides to derive the symmetric session key.

4.4 Server Final Response

The server uses the pre‑master secret to compute the session key, then sends:

ChangeCipherSpec.

Finished message with a hash for the client to verify.

After this, the handshake is complete and the client and server continue communication over HTTP encrypted with the session key.