Chapter 5: HTTPS & TLS

---

Metadata Card

Attribute	Value
Difficulty
Prerequisites	HTTP basics (Chapter 4), symmetric/asymmetric encryption basics
Core Concepts	TLS handshake, certificate chain, key exchange, forward secrecy
Practical Skills	Read TLS 1.2/1.3 handshake logs, configure certificate chains, troubleshoot common TLS errors

---

Your Progress

"But you soon discover a problem — there are bandits on the post road. The spell messages you transmit on the post road are plain text — any wild mage can peek. HTTPS and TLS add a sealing lock to this post road — only the sender and receiver can open it."

From Chapter 4's HTTP, you understand: HTTP is a plain text, naked transmission spell — vulnerable to man-in-the-middle sniffing, tampering, and impersonation.

You → [plaintext "secret:123456"] → anyone can see → beacon tower

Your task is one word: Lock. That's HTTPS — HTTP + TLS (Transmission Array Security), not HTTP + SSL. SSL is long deprecated, but the name SSL lingers in toolkits and ecosystems.

Core Fact: HTTPS is not a new protocol. It is HTTP over TLS.

TLS itself doesn't belong to the application layer — it inserts a "security sealing spell" layer between the transmission spell (TCP) and application layer (HTTP):

Application Layer:  HTTP
Security Layer:     TLS
Transport Layer:    TCP
Post Road Layer:    IP

TLS 1.2 Handshake — Six Steps

TLS 1.2 handshake is the baseline for understanding all modern encrypted communication. Don't skip it to learn TLS 1.3 directly — you won't know what it simplified.

Client                              Server
  │                                    │
  │ 1. ClientHello ───────────────────→│
  │    (TLS version, cipher list, nonce)│
  │                                    │
  │ 2. ←── ServerHello                 │
  │    (selected version/cipher, nonce)│
  │                                    │
  │ 3. ←── Certificate                 │
  │    (server certificate chain)      │
  │                                    │
  │ 4. ←── ServerHelloDone             │
  │                                    │
  │ 5. ClientKeyExchange ────────────→│
  │    (PreMaster encrypted with pub key)│
  │                                    │
  │ 6. ──── Both compute MasterSecret  │
  │                                    │
  │ 7. ChangeCipherSpec ─────────────→│
  │    "Now communicating with symmetric key"│
  │                                    │
  │ 8. Finished ─────────────────────→│
  │    (encrypted handshake digest)    │
  │                                    │
  │ 9. ←── ChangeCipherSpec           │
  │ 10. ←── Finished                   │
  │                                    │
  │ ═══════ TLS Tunnel Established ════│

Cipher Suite Breakdown

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│    │     │    │    │     │    │
│    │     │    │    │     │    └─ PRF/verification hash
│    │     │    │    │     └─────── Symmetric encryption mode
│    │     │    │    └───────────── Symmetric cipher + key length
│    │     │    └───────────────── Certificate signing algorithm
│    │     └───────────────────── Key exchange algorithm
│    └─────────────────────────── Key exchange + certificate system

Certificate Chain Verification

Root CA (self-signed, built into OS/browser)
    │ "I verified the next level"
    ▼
Intermediate CA
    │ "I verified the website"
    ▼
Leaf Certificate (the server cert you see with curl)

Forward Secrecy

Traditional RSA key exchange: client encrypts PreMasterSecret with server's public key. If an attacker obtains the server's private key later, they can decrypt this PreMasterSecret — and thus decrypt all previous traffic.

ECDHE solves this: The server generates an ephemeral key pair that's thrown away after use. Even if the attacker gets the server's permanent private key in 2026, the session keys from 2024 were negotiated via ECDHE and cannot be recovered.

TLS 1.3 Handshake — One Step Instead of Six

TLS 1.3 reduces 2-RTT to 1-RTT (and even 0-RTT).

Change	Why
Removed RSA key exchange	Algorithms without forward secrecy don't deserve to exist
Removed insecure symmetric algorithms	DES, RC4, 3DES, CBC mode - all cut
Handshake messages encrypted	All messages after ServerHello are encrypted
0-RTT (session resume)	Cache from last handshake + PSK, no extra round trips
Simplified cipher suites	Key exchange and signature negotiated independently

Key Insight: HTTPS is NOT a new protocol. It's the existing HTTP protocol running inside a TLS tunnel. TLS handles encryption, authentication, and integrity.

---

Traveler's Notes

• The first TLS handshake is the slowest — subsequent connections can reuse session IDs or Session Tickets to skip a full handshake
• Chrome DevTools' Security panel shows TLS version and certificate info — check there before opening Wireshark
• curl -v https://example.com is the fastest TLS debugging tool
• Self-signed certificates work for development; production must not bypass CA verification

---

→ Next Stop Preview

WebSocket transforms HTTP into full-duplex persistent connections; gRPC uses Protocol Buffers to redefine remote calls. Next chapter: "Modern Protocols: WebSocket & gRPC".