TLS/SSL and PKI Complete Guide — Handshake, Certificate Chain, Cipher Suites, 0-RTT, and the Post-Quantum Era (2025)

0. The Weight of a Padlock

The tiny padlock in the address bar. Users rarely look at it for two seconds. Yet behind it sits:

• Netscape's SSL 1.0 prototype (1994).
• IETF TLS 1.0 standardization (1999).
• Heartbleed, arguably the worst internet bug in history (2014).
• The TLS 1.3 overhaul (2018).
• Chrome rolling out post-quantum Kyber in production (2024).

Every HTTPS request asks three questions: "Can I trust a server I have never met?", "Is anyone eavesdropping?", "Was this packet tampered with?" TLS and PKI answer all three.

This post goes inside the machine: what actually happens when you click the padlock, why TLS 1.3 is twice as fast as 1.2, why Let's Encrypt was a revolution, and why we are scrambling to deploy post-quantum crypto in 2024.

1. The Three Problems TLS Solves

1.1 Confidentiality

Plaintext HTTP on shared WiFi is readable with one tcpdump. The 2010 Firesheep extension stole Facebook session cookies from cafe networks and popularized HTTPS.

Fix: symmetric encryption (AES, ChaCha20) with a shared key.

1.2 Integrity

A MITM turning "send $1" into "send$10,000" defeats encryption alone if the ciphertext still decrypts to something valid.

Fix: MAC or AEAD (AES-GCM, ChaCha20-Poly1305).

1.3 Authentication

If "google.com" is actually an attacker's server, neither encryption nor integrity helps.

Fix: X.509 certificates + PKI. A CA vouches for the server's identity.

2. Asymmetric Crypto — Secrets Without Shared Keys

2.1 The First-Meeting Dilemma

Two strangers need a shared key to encrypt, but how do they exchange it? Sending it plaintext leaks it.

2.2 Diffie-Hellman (1976)

Diffie, Hellman, Merkle (Turing Award 2002):

Alice                           Bob
public g, p (p a large prime)

a = random()                    b = random()
A = g^a mod p                   B = g^b mod p
        send A →
        ← receive B

shared = B^a mod p              shared = A^b mod p
       = g^(ab) mod p           = g^(ab) mod p

A MITM sees A and B but needs a or b to compute g^(ab) — the discrete log problem, infeasible on classical hardware.

2.3 RSA (1977)

Rivest, Shamir, Adleman:

public key: (n, e)   (n = p*q, p,q secret primes)
private key: d       (d*e ≡ 1 mod φ(n))

encrypt: c = m^e mod n
decrypt: m = c^d mod n

Security rests on integer factorization being hard classically.

2.4 Coexistence

Early TLS (1994–2010) leaned on RSA key exchange: client encrypts a pre-master secret with the server's public key. Problem: no forward secrecy — a later private-key leak decrypts every past session.

Post-2010, DHE/ECDHE (ephemeral) took over. TLS 1.3 removes RSA key exchange entirely; only ECDHE remains.

2.5 ECC — Same Security, Fewer Bits

ECC 256 roughly equals RSA 3072. Modern TLS defaults to ECC.

3. TLS 1.2 Handshake — The 2-RTT Dance

Client                              Server
  │   ClientHello                    │
  │────────────────────────────────→│
  │   ServerHello                    │
  │   Certificate                    │
  │   ServerKeyExchange              │
  │   ServerHelloDone                │
  │←────────────────────────────────│
  │   ClientKeyExchange              │
  │   ChangeCipherSpec               │
  │   Finished (encrypted)           │
  │────────────────────────────────→│
  │   ChangeCipherSpec               │
  │   Finished (encrypted)           │
  │←────────────────────────────────│
  │   Application Data (encrypted)   │
  │←──────────────────────────────→│

Two round trips before data flows. At 100ms RTT that is 200ms of pure latency — a major bottleneck for page load.

3.1 Decoding a Cipher Suite

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:

• ECDHE: key exchange.
• RSA: authentication.
• AES_128_GCM: AEAD cipher.
• SHA256: hash for MAC/PRF.

Hundreds of combinations existed, including unsafe ones like "null cipher" and "export-grade 40-bit" — the roots of the FREAK and Logjam attacks.

3.2 TLS 1.2 Weaknesses

• Slow 2-RTT.
• Too many knobs, too many misconfigurations (512-bit DH = Logjam).
• MAC-then-Encrypt vulnerabilities (Lucky 13, POODLE).
• RSA key exchange = no forward secrecy.

4. TLS 1.3 — The 2018 Surgery

4.1 Design Philosophy

"Remove unsafe options. Eliminate misconfiguration surface."

4.2 1-RTT Handshake

Client                              Server
  │  ClientHello                    │
  │  (key_share: ECDHE pub,         │
  │   supported_versions: [1.3])    │
  │────────────────────────────────→│
  │  ServerHello                    │
  │  (key_share: ECDHE pub)         │
  │  { EncryptedExtensions,         │
  │    Certificate,                  │
  │    CertificateVerify,            │
  │    Finished }                    │
  │←────────────────────────────────│
  │  { Finished }                    │
  │  Application Data (encrypted)    │
  │────────────────────────────────→│

The client speculatively sends an ECDHE public key in ClientHello. Server returns everything in one flight. One RTT — twice as fast as 1.2.

4.3 What Got Removed

• RSA key exchange.
• CBC mode (only AEAD remains).
• Renegotiation.
• Compression (CRIME mitigation).
• MD5, SHA-1.
• Weak curves (secp224, etc.).

Only five cipher suites remain:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256

Structurally almost impossible to misconfigure.

4.4 0-RTT Resumption

On reconnection the client can attach application data to ClientHello itself. Mobile apps and SPAs feel this as "instant".

4.5 0-RTT Replay Risk

0-RTT data has no forward secrecy and can be replayed. Mitigation: allow only idempotent requests (GET), and have the server track a replay-detection window (HTTP/3 does this).

4.6 Adoption

RFC 8446 in 2018 to broad browser support by 2020. In 2024 over 90% of HTTPS traffic uses TLS 1.3.

5. Certificate Chains — Trusting a Stranger

5.1 Chain Structure

[Root CA: DigiCert Global Root CA]       ← preinstalled in browser/OS
       │ (signs)
       ▼
[Intermediate CA: DigiCert TLS RSA SHA256 2020 CA1]
       │ (signs)
       ▼
[End-entity: google.com]                 ← served by the server

Browser verifies google.com via the intermediate's pubkey, verifies the intermediate via the root's pubkey, and trusts the root because it is already baked in.

5.2 Inside an X.509 Certificate

Certificate:
    Version: 3
    Serial Number: 04:a2:...
    Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1
    Validity:
        Not Before: Jan 1 2025
        Not After:  Apr 1 2026
    Subject: C=US, O=Google LLC, CN=*.google.com
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
        Public Key: <2048 bits>
    X509v3 Extensions:
        Subject Alt Name: DNS:*.google.com, DNS:google.com, ...
        Key Usage: Digital Signature, Key Encipherment
        Extended Key Usage: TLS Web Server Authentication
        Authority Information Access: OCSP - http://...
        Certificate Policies: 2.23.140.1.2.2 (Organization Validated)
    Signature: <signed by Intermediate CA>

5.3 Three CA Validation Levels

• DV (Domain Validation): proves domain control. ~90% of HTTPS. Let's Encrypt.
• OV (Organization Validation): manual company verification.
• EV (Extended Validation): deep legal-entity checks. Browsers stopped showing the green bar in 2019.

5.4 Where Root Trust Comes From

Root CAs are hardcoded in the browser/OS:

• Windows/Edge: Microsoft Trust Store.
• macOS/Safari/iOS: Apple Root CA List.
• Firefox: Mozilla's independent list.
• Chrome: historically OS store, moving to its own Root Store since 2023.

Each vendor runs a rigorous audit program for inclusion.

5.5 Famous CA Failures

• 2011 DigiNotar: hacked, issued fake google.com certs used by Iran for Gmail surveillance. CA went bankrupt.
• 2015 CNNIC: an Egyptian reseller issued arbitrary certs. Some CNNIC roots removed.
• 2017 Symantec: years of sloppy validation. Google drove phased distrust. Symantec sold its CA business to DigiCert.

One compromised CA compromises the whole web — hence the next layer.

6. Certificate Transparency — Democratized Auditing

6.1 The Problem Restated

If a CA mis-issues a cert, victims have no way to know.

6.2 The Idea

"Log every new certificate in a public, append-only log."

CAs submit issued certs to multiple CT log servers. Each log uses a Merkle tree. A Signed Certificate Timestamp (SCT) is attached to the cert; browsers verify it. Since 2018 Chrome requires SCTs on all new certs.

6.3 Effects

Domain owners can query crt.sh for any cert issued under their names. Anomalies are caught quickly.

6.4 crt.sh Side Effects

Search your own domain on crt.sh and you may find: forgotten staging subdomains, typosquats like g00gle.com, leftover subdomains from former contractors.

7. Let's Encrypt — HTTPS for Everyone (2016)

7.1 Pre-2015 Reality

HTTPS cost tens of dollars a year, required manual renewal, and hard installs. Only ~30% of the web ran HTTPS.

7.2 Three Innovations

1. Free (funded by Mozilla, EFF, Akamai, Cisco, donations).
2. Automated via ACME — one certbot command.
3. Short 90-day lifetimes forcing auto-renewal.

7.3 ACME Protocol

1. Create account (register public key)
2. Order: "I want a cert for example.com"
3. Challenge:
   - HTTP-01: place a token at http://example.com/.well-known/acme-challenge/TOKEN
   - DNS-01:  set _acme-challenge.example.com TXT = value
4. Server validates challenge
5. Submit CSR, receive certificate

7.4 Numbers

~400 million active certs in 2024. Crucial to crossing 90% HTTPS adoption globally.

7.5 Competitors

ZeroSSL, Buypass, AWS Certificate Manager, and integrated CDN issuance from Cloudflare and Fastly.

8. Revocation — The Unsolved Problem

8.1 Why It Is Hard

A stolen key needs to revoke a still-valid certificate. How do you tell every browser?

8.2 CRL

CA publishes a list of revoked serials. Too large to download each time; browsers mostly skip it.

8.3 OCSP

Ask the CA "is this cert valid?" per connection. Three problems: privacy leak to the CA, fail-open vs fail-closed dilemma (most go fail-open, making it toothless), and added RTT.

8.4 OCSP Stapling

Server fetches OCSP response periodically and includes it in the handshake. Fixes privacy and RTT — but adoption is spotty.

8.5 Push-Based in Practice

Chrome ships CRLSet, Firefox ships OneCRL — curated lists of urgent revocations pushed to clients. That is what actually works today.

8.6 Short Lifetimes as Compromise

Since revocation is broken, rotate often. Let's Encrypt's 90 days. Apple capped TLS cert lifetimes at 398 days in 2022.

9. HSTS, HPKP, CAA — Defense in Depth

9.1 HSTS

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

"Never speak HTTP to this host again for a year." preload gets you shipped into Chrome's built-in list.

9.2 HPKP Failed

Public Key Pinning could brick a domain forever if misconfigured. Chrome retired it in 2018. CT solves the same problem more safely.

9.3 CAA

DNS record restricting which CAs may issue for your domain:

example.com. CAA 0 issue "letsencrypt.org"

CAs have been required to honor CAA since 2017.

10. A Brief History of TLS Attacks

10.1 Heartbleed (2014)

An OpenSSL heartbeat bug: client claims "I sent 16 bytes" while sending 1, server returns 16 bytes of its own memory. Leaked private keys, sessions, passwords. Spawned the Linux Foundation Core Infrastructure Initiative.

10.2 BEAST, POODLE, Lucky 13

CBC-mode padding attacks that accelerated the migration to AEAD (GCM).

10.3 FREAK, Logjam (2015)

Forced downgrade to 512-bit "export" keys — a 1990s US export-control relic weaponized 15 years later. Lesson: leaving legacy modes on lets attackers downgrade into them. TLS 1.3 is aggressive about cutting old code for this reason.

10.4 DROWN, Sweet32 (2016)

Exploit leftover SSLv2 or 3DES support to attack modern connections.

10.5 Raccoon, ALPACA (2020–2021)

Last-generation TLS 1.2 attacks. TLS 1.3 is unaffected — a reason to upgrade.

11. Post-Quantum Crypto — The Urgent 2024 Shift

11.1 Harvest Now, Decrypt Later

If large quantum computers arrive in the 2030s, Shor's algorithm breaks RSA and ECC. Attackers can record traffic today and decrypt later. Anything needing 30-year secrecy (health, state secrets) needs quantum resistance now.

11.2 NIST PQC Standards (2024)

• ML-KEM (Kyber): key encapsulation, replaces RSA/ECDHE.
• ML-DSA (Dilithium): signatures, replaces ECDSA.
• SLH-DSA (SPHINCS+): hash-based signatures.

Mostly lattice-based — believed hard even for quantum computers.

11.3 Hybrid

Run classical ECDH and Kyber in parallel; break both to decrypt:

key = HKDF(ECDH(x25519) || Kyber768)

11.4 Chrome Deployment (2024)

Chrome 116+ enabled X25519Kyber768 by default in August 2024. Handshakes grew by Kyber's 1.2KB public key; ~1ms extra CPU. Some middleboxes choked on "post-quantum bytes too large" causing brief rollback. Cloudflare and AWS shipped similar hybrids.

11.5 Remaining Work

Signature migration is slower (Dilithium signatures are 3–5KB), IoT devices struggle with Kyber cost, certificate chains balloon to tens of KB, and migrating the entire PKI (roots, certs, CRLs) will take years.

12. Operational TLS — Checklist

12.1 nginx Example

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 valid=300s;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

12.2 Tools

• SSL Labs (aim for A+).
• testssl.sh for local deep checks.
• Hardenize for DNS + mail + web.
• Chrome DevTools Security panel.

12.3 Performance

• OCSP stapling on.
• HTTP/2 or HTTP/3 over TLS 1.3.
• Session resumption (session tickets or IDs) plus 0-RTT where safe.
• ECDSA certs save CPU versus RSA.

12.4 Monitoring

• Expiry alerts 30 days out.
• CT log watchers (crt.sh Watchtower, Cert Spotter).
• TLS version usage stats to catch old clients.

13. Closing — What the Padlock Tells Us

The journey from 1994 Netscape SSL 1.0 has produced:

• Protocol simplification: hundreds of ciphers down to five.
• Automation: hand-issued certs to ACME.
• Transparency: black-box CAs to public CT logs.
• Speed: 2-RTT to 1-RTT to 0-RTT.
• Economics: paid to free.
• Safety: a feedback loop of attacks and fixes.

In 2024 a new threat class — quantum computing — forced the entire stack to move again. The infrastructure built over 30 years will likely be rebuilt to be quantum-safe within ten.

Every padlock silently runs the combined work of decades of mathematicians, engineers, and standards bodies.

References

• RFC 8446 — TLS 1.3.
• RFC 8555 — ACME.
• Ivan Ristic, "Bulletproof SSL and TLS" (Feisty Duck, 2022).
• Eric Rescorla, "SSL and TLS: Designing and Building Secure Systems".
• NIST FIPS 203/204/205 (ML-KEM, ML-DSA, SLH-DSA).
• Cloudflare blog — TLS 1.3 and Post-Quantum series.
• Mozilla Server Side TLS Guidelines.
• Let's Encrypt engineering blog.
• crt.sh.
• SSL Labs Best Practices.