How SSL/TLS Works: The TLS Handshake Explained

Every time you visit an HTTPS website, your browser and the server perform a TLS handshake — a rapid exchange that authenticates the server, agrees on encryption parameters, and derives a shared secret key. This happens in 1-2 network round trips (50-200ms) before any page content loads.

The TLS 1.3 handshake (current standard)

TLS 1.3 completes the handshake in a single round trip (1-RTT):

Step 1 — Client Hello Your browser sends: supported TLS versions, supported cipher suites, a random number, and key share parameters (for Diffie-Hellman key exchange).

Step 2 — Server Hello + Certificate + Finished The server responds with: chosen cipher suite, its certificate (proving its identity), its key share, and a “Finished” message. In TLS 1.3, the certificate is encrypted — passive observers can’t see which site you’re connecting to.

Step 3 — Client Finished The browser verifies the certificate against its trusted CA list, computes the shared session key from the Diffie-Hellman exchange, and sends its “Finished” message. Encrypted application data can now flow.

Total: 1 round trip. Resumed connections (where the client has connected before) can use 0-RTT — sending encrypted data with the very first message.

TLS 1.2 handshake (still widely used)

TLS 1.2 requires 2 round trips:

1. Client Hello → supported versions, ciphers, random number
2. Server Hello → chosen cipher, certificate, server key exchange
3. Client Key Exchange → pre-master secret (encrypted with server’s public key or via Diffie-Hellman)
4. Change Cipher Spec + Finished (both sides)

TLS 1.2 supports more cipher suites — including some weak ones. Proper configuration matters more than with TLS 1.3.

What happens inside the encrypted connection

After the handshake, all data is encrypted with the negotiated session key using a symmetric cipher (typically AES-256-GCM or ChaCha20-Poly1305):

• Confidentiality — data is encrypted; only the two endpoints can read it
• Integrity — each message includes a MAC (message authentication code); any tampering is detected
• Authentication — the server’s certificate proves its identity (and optionally, the client’s)

Every HTTP request and response — headers, body, cookies, URLs — travels through this encrypted channel.

Forward secrecy

Modern TLS uses ephemeral Diffie-Hellman key exchange, which means every connection generates a unique session key. Even if the server’s private key is compromised later, past conversations cannot be decrypted.

TLS 1.3 makes forward secrecy mandatory. TLS 1.2 supports it but also allows RSA key exchange (which doesn’t provide forward secrecy). This is why TLS 1.3 is preferred.

The certificate’s role

The TLS handshake depends on the server having a valid SSL/TLS certificate. The certificate provides:

1. The server’s public key — used during key exchange
2. Domain name(s) — the browser checks these match the URL
3. CA signature — proves a trusted Certificate Authority vouches for this certificate
4. Validity dates — the browser rejects expired certificates

Without a valid certificate, the handshake fails and the browser shows a security warning. Get a free certificate →

Performance

On modern hardware, the CPU cost of encryption is negligible — AES-NI instructions handle it in hardware. The main cost is the extra round trip(s), which TLS 1.3 minimizes.

What you can see on the wire

Without HTTPS (HTTP)

An observer on the network sees everything:

GET /login HTTP/1.1
Host: example.com
Cookie: session=abc123

username=admin&password=secret123

Usernames, passwords, cookies, page content — all in plaintext.

With HTTPS (TLS)

The same observer sees:

[TLS handshake — server certificate visible in TLS 1.2, encrypted in TLS 1.3]
[Encrypted application data — indistinguishable from random bytes]
[Encrypted application data]
[Encrypted application data]

They can see the destination IP address and the SNI hostname (in TLS 1.2 — encrypted in TLS 1.3 with ECH). They cannot see the URL path, headers, body, or cookies.

How the certificate fits in

The TLS handshake depends on the server having a valid SSL/TLS certificate:

1. The server’s public key — used during key exchange
2. Domain name(s) — the browser checks these match the URL
3. CA signature — proves a trusted Certificate Authority vouches for this certificate
4. Validity dates — the browser rejects expired certificates

Without a valid certificate, the handshake fails and the browser shows a security warning. Get a free certificate →

Common TLS cipher suites in 2026

TLS 1.3 (only 5 cipher suites — all secure)

TLS_AES_256_GCM_SHA384       ← Most common
TLS_AES_128_GCM_SHA256       ← Widely used
TLS_CHACHA20_POLY1305_SHA256 ← Best for mobile/ARM
TLS_AES_128_CCM_SHA256       ← IoT/embedded
TLS_AES_128_CCM_8_SHA256     ← IoT/embedded (short tag)

TLS 1.2 (use only AEAD suites)

ECDHE-ECDSA-AES256-GCM-SHA384  ← Best with ECC cert
ECDHE-RSA-AES256-GCM-SHA384    ← Best with RSA cert
ECDHE-ECDSA-CHACHA20-POLY1305  ← Mobile-optimized

Avoid non-AEAD suites (CBC mode) in TLS 1.2 — they’ve been vulnerable to attacks like BEAST and Lucky13.

Frequently asked questions

Does HTTPS slow down my website?

The TLS handshake adds one round trip (TLS 1.3) or two (TLS 1.2) on the first connection. Session resumption eliminates this for returning visitors. Since HTTPS enables HTTP/2 (multiplexing, header compression), HTTPS sites are often faster overall.

What is a cipher suite?

A cipher suite is a combination of algorithms used for key exchange, encryption, and message authentication. Example: TLS_AES_256_GCM_SHA384 means TLS with AES-256-GCM encryption and SHA-384 for message integrity. TLS 1.3 has only 5 cipher suites — all secure. TLS 1.2 has 37, some of which are weak.

Can someone decrypt HTTPS traffic later?

Not with forward secrecy (ephemeral key exchange). Each session uses a unique key derived from Diffie-Hellman exchange. Even if the server’s long-term private key is compromised, past session keys cannot be recovered. TLS 1.3 enforces this; TLS 1.2 supports it when configured correctly.

How does GetHTTPS relate to this?

GetHTTPS generates the certificate that makes the TLS handshake possible. The certificate contains the public key the server uses during key exchange. GetHTTPS creates this key pair in your browser using the Web Crypto API and connects directly to Let’s Encrypt’s ACME API to get it signed. How GetHTTPS works →