How SSL/TLS Works: The Handshake Explained

Scenario context

SSL (now TLS) secures data between your browser and a server. It uses Asymmetric Encryption (Public/Private keys) once — to safely exchange a fast Symmetric Session Key. Everything after the handshake is encrypted with the session key.

Alice wants to send Bob a secret letter, but Eve is intercepting all mail.

• Symmetric encryption: Same key locks and unlocks. Fast — but how do Alice and Bob share…

This walkthrough focuses on The Locked Box Trick: Why Two Encryption Systems?.

Before making a design choice, clarify:

• Alice wants to send Bob a secret letter, but Eve is intercepting all mail.
• • Symmetric encryption: Same key locks and unlocks.
• Fast — but how do Alice and Bob share the key without Eve intercepting it?

Concepts in play: api-security-oauth2, jvm-internals-and-garbage-collection, system-design-hld-architectures

Stage 1 — The TLS 1.3 Handshake: Step by Step

• This happens in milliseconds every time you visit https://google.com .
• The handshake sequence reveals TLS 1.3's core insight: asymmetric and symmetric cryptography are used in strict sequence, never interchangeably.
• The browser and server exchange ECDH public values in the Key Share messages — neither side ever transmits the session key directly; both independently derive the same shared secret from the ECDH mathematics, which is w…
• The Verify certificate note is the trust anchor of the entire protocol: if the server's certificate does not chain to a CA pre-installed in the OS trust store, the handshake aborts here before any key material is derive…

sequenceDiagram
    participant B as Browser (Client)
    participant S as Server (google.com)

    B->>S: ClientHello (TLS version, cipher suites, random nonce)
    S->>B: ServerHello (chosen cipher, random nonce)
    S->>B: Certificate (server's public key, signed by CA)
    S->>B: Key Share (ECDH public value)
    Note over B: Verify certificate against trusted CAs
    B->>S: Key Share (browser's ECDH public value)
    Note over B,S: Both derive the same Session Key independently
    B->>S: Finished (encrypted with session key)
    S->>B: Finished (encrypted with session key)
    Note over B,S: Handshake complete  all further data encrypted

Observable outcome: The Verify certificate note is the trust anchor of the entire protocol: if the server's certificate does not chain to a CA pre-installed in the OS trust store, the handshake aborts here before any key material is derive…

Stage 2 — Certificates and the Chain of Trust

• Your browser doesn't know every website.
• It knows a small set of Root CAs (DigiCert, Let's Encrypt, GlobalSign) pre-installed in your OS/browser trust store.
• The three-node chain encodes a critical operational security decision: Root CA private keys are kept offline in air-gapped HSMs and never used for day-to-day certificate signing.
• The Intermediate CA handles routine leaf certificate issuance and can be revoked independently — if an Intermediate is compromised, the Root issues a new CRL excluding it, and only that Intermediate's issued certificate…

flowchart TD
    Root["Root CA (Self-Signed  in your OS trust store)"]
    Intermediate["Intermediate CA (Signed by Root)"]
    Leaf["Leaf Certificate google.com (Signed by Intermediate)"]

    Root --> Intermediate --> Leaf

Observable outcome: The Intermediate CA handles routine leaf certificate issuance and can be revoked independently — if an Intermediate is compromised, the Root issues a new CRL excluding it, and only that Intermediate's issued certificate…

Stage 3 — The Full TLS Handshake as a Decision Flowchart

• The sequence diagram above shows what messages are sent.
• This flowchart shows why the handshake can succeed or fail — including the critical certificate validation branch that determines whether a secure channel opens or the browser shows a red warning.
• The decision branch at step 3 — "Root CA in trust store?" — is where the vast majority of real-world TLS errors originate: expired leaf certificates, incomplete chains where the server forgot to include the Intermediate…
• Steps 1 through 4 complete in a single network round trip in TLS 1.3: the browser sends its ECDH key share and the Finished message in the same flight, so the server can derive the session key and reply without waiting…

flowchart TD
    A[1 Browser sends ClientHello TLS version + cipher suites + random nonce] --> B[2 Server sends ServerHello Chosen cipher + Certificate + ECDH key share]
    B --> C[3 Browser checks certificate chain Leaf  Intermediate  Root CA]
    C --> D{Root CA in trust store?}
    D -- "No / Expired" --> E[ Handshake aborted Browser shows 'Not Secure' warning]
    D -- "Yes" --> F[4 Browser sends its ECDH key share]
    F --> G[5 Both sides independently derive the same Session Key from ECDH values]
    G --> H[6 Both send Finished message encrypted with the new session key]
    H --> I[ Encrypted channel open All traffic protected with AES-GCM]

Observable outcome: Steps 1 through 4 complete in a single network round trip in TLS 1.3: the browser sends its ECDH key share and the Finished message in the same flight, so the server can derive the session key and reply without waiting…

Stage 4 — Real-World Applications: Where TLS Secures the Web: Real-World Applications

• TLS is not just for web browsers — it underpins virtually every secure channel on the modern internet.
• HTTPS websites — Every site with a padlock icon uses TLS.
• When you log in, check out, or submit a form, TLS ensures no one between your device and the server can read or tamper with the data in transit.
• REST APIs and microservices — When your mobile app calls a payment gateway, TLS encrypts the request and response.

Observable outcome: REST APIs and microservices — When your mobile app calls a payment gateway, TLS encrypts the request and response.

Stage 5 — Deep Dive: Session Keys, Forward Secrecy, and Performance

• ECDH and Perfect Forward Secrecy (PFS) In TLS 1.3, the session key is derived via ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).
• "Ephemeral" means a fresh key pair is generated for every session and discarded after.
• Perfect Forward Secrecy: Even if an attacker records encrypted traffic today and steals the server's private key tomorrow, they cannot decrypt past sessions — because the ephemeral ECDH keys are long gone.
• TLS 1.2 without PFS (RSA key exchange): steal the private key → decrypt all stored traffic.

Observable outcome: TLS 1.2 without PFS (RSA key exchange): steal the private key → decrypt all stored traffic.

Stage 6 — Checking and Configuring TLS in Practice

• This example demonstrates a practical scenario.
• The code below shows the key implementation details you need to understand.
• Follow along to see how this works in practice.
• Inspect a site's certificate from your terminal: Minimal secure Nginx TLS configuration with Let's Encrypt: Automate certificate renewal (Let's Encrypt certificates expire every 90 days): Common beginner mistake: Leavin…

# View certificate details (subject, issuer, validity dates)
openssl s_client -connect google.com:443 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -text \
  | grep -E "Subject:|Issuer:|Not (Before|After)"

# Quick expiry check for your own domain
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null \
  | openssl x509 -noout -dates

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    # Enforce TLS 1.2 minimum; prefer TLS 1.3
    ssl_protocols TLSv1.2 TLSv1.3;

    # ECDHE ciphers only — ensures Perfect Forward Secrecy
    ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

    # HSTS — tells browsers to always use HTTPS for the next year
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Observable outcome: Inspect a site's certificate from your terminal: Minimal secure Nginx TLS configuration with Let's Encrypt: Automate certificate renewal (Let's Encrypt certificates expire every 90 days): Common beginner mistake: Leavin…

End-to-end outcome

Alice wants to send Bob a secret letter, but Eve is intercepting all mail.

Alternatives considered

Symmetric vs. Asymmetric: The Two Locks Every Browser Uses

Before TLS can protect anything, both sides need to agree on a secret — without ever having met.

Decision Guide: Configuring TLS for Your Use Case

Use TLS 1.3 whenever possible — it's faster and more secure than 1.2.

Failure and degraded modes

Trade-offs & Failure Modes: Common Misconfigurations and mTLS

• Detection: mTLS (Mutual TLS): In standard TLS, only the server presents a certificate.
• User or operator impact: mTLS (Mutual TLS): In standard TLS, only the server presents a certificate.