Chapter 08 — HTTPS & TLS (How the Web Is Secured)

Shreyesh kolhe
July 10, 2026

Chapter 08 — HTTPS & TLS (How the Web Is Secured)

Hey everyone! Welcome back to Namaste Computer Networks! 🙏

Plain HTTP sends everything as readable text — your passwords, your card number, everything — so anyone between you and the server (your ISP, a café's WiFi, a hacker) can read or tamper with it. HTTPS fixes this with encryption via TLS. That little padlock in your browser is doing serious work. Let's understand it without the scary math.

What we will cover:

  • HTTP vs HTTPS (the sealed envelope)
  • The 3 guarantees: encryption, integrity, authentication
  • Symmetric vs asymmetric encryption (the key idea)
  • The TLS handshake, simply
  • Certificates & Certificate Authorities
  • Interview Questions

1. HTTP vs HTTPS

   HTTP  = a POSTCARD 📬. Every router along the way can read it.
           "password=hunter2" travels in plain sight. 😱

   HTTPS = a SEALED, LOCKED BOX 🔒. Only the destination can open
           it. Snoopers see scrambled gibberish.

┌─────────────────────────────────────────────────────────────┐
│   HTTPS = HTTP + TLS (encryption). Same HTTP underneath, but  │
│   wrapped in a secure, encrypted tunnel.                      │
└─────────────────────────────────────────────────────────────┘

2. The 3 Guarantees of TLS

   1. ENCRYPTION     → data is scrambled; only the two parties can
                       read it. (Privacy: no eavesdropping.)

   2. INTEGRITY      → if data is tampered with in transit, it's
                       detected and rejected. (No secret changes.)

   3. AUTHENTICATION → you're really talking to the REAL site, not
                       an imposter. (Via certificates — section 5.)

   Together: private, untampered, and to the genuine server.

3. Symmetric vs Asymmetric Encryption

TLS cleverly combines two types of encryption. Understanding the difference is the key insight.

┌─────────────────────────────────────────────────────────────┐
│   SYMMETRIC → ONE shared secret key locks AND unlocks.        │
│     ✔ Fast. ✗ Problem: how do both sides get the same secret  │
│       key without a snooper stealing it in transit?          │
│                                                             │
│   ASYMMETRIC → a KEY PAIR: a PUBLIC key (shared with anyone)  │
│     and a PRIVATE key (kept secret).                         │
│     Anything locked with the public key can ONLY be unlocked  │
│     by the matching private key.                             │
│     ✔ Solves key exchange. ✗ Slow (heavy math).             │
└─────────────────────────────────────────────────────────────┘

   THE TRICK TLS USES:
   Use SLOW asymmetric encryption ONCE, just to safely agree on a
   shared symmetric key. Then use FAST symmetric encryption for
   all the actual data. Best of both worlds. 🌟

4. The TLS Handshake (Simplified)

TRACE:  browser connects to https://bank.com
──────────────────────────────────────────────
  1. "Client Hello": browser says hi, lists supported ciphers
  2. Server sends its CERTIFICATE (contains its PUBLIC key)
  3. Browser VERIFIES the certificate (is it genuine? section 5)
  4. Browser & server use asymmetric crypto to securely agree on
     a shared SYMMETRIC "session key" (a snooper can't derive it)
  5. From now on, ALL data is encrypted with that fast session key
  6. Encrypted HTTP flows. 🔒 ✅

   This happens in milliseconds, once, at the start of the
   connection. (It sits on top of the TCP handshake from Ch 05.)

5. Certificates & Certificate Authorities

   Problem: anyone can send a public key claiming "I'm bank.com."
   How do you TRUST it's really the bank and not an imposter?

   Solution: a CERTIFICATE — a document proving a public key
   belongs to a specific domain, digitally SIGNED by a trusted
   CERTIFICATE AUTHORITY (CA) like Let's Encrypt, DigiCert.

   Your browser ships with a list of trusted CAs. When bank.com's
   certificate is signed by a CA your browser trusts → ✅ padlock.
   If it's self-signed, expired, or for the wrong domain →
   ⚠️ "Your connection is not private" warning.

   CHAIN OF TRUST:
   Browser trusts CA → CA vouched for bank.com's certificate
   → therefore browser trusts bank.com. Like a passport: you
   trust it because a trusted government issued it.

Interview Questions — Quick Fire!

Q: What's the difference between HTTP and HTTPS?

"HTTPS is HTTP secured with TLS encryption. Plain HTTP sends data as readable text, so anyone in the network path can read or tamper with it. HTTPS wraps the same HTTP in an encrypted tunnel, providing privacy, integrity, and authentication of the server. The underlying protocol is identical — HTTPS just adds the TLS security layer."

Q: What guarantees does TLS provide?

"Three: encryption, so the data is scrambled and only the two parties can read it; integrity, so any tampering in transit is detected and rejected; and authentication, so you can verify you're really communicating with the genuine server and not an imposter, using certificates."

Q: What's the difference between symmetric and asymmetric encryption, and how does TLS use both?

"Symmetric encryption uses one shared key to both encrypt and decrypt — it's fast but requires both sides to already share the secret. Asymmetric encryption uses a public-private key pair, where data encrypted with the public key can only be decrypted with the private key — it solves key exchange but is slow. TLS uses asymmetric encryption once to securely agree on a shared symmetric session key, then uses fast symmetric encryption for the actual data, combining the strengths of both."

Q: What is a TLS/SSL certificate and why do we need a Certificate Authority?

"A certificate proves that a public key belongs to a specific domain, and it's digitally signed by a trusted Certificate Authority. We need a CA because anyone could otherwise claim to own a domain and present their own key for a man-in-the-middle attack. Browsers ship with a list of trusted CAs, so a certificate signed by one of them establishes a chain of trust confirming the server's identity."

Q: What happens during a TLS handshake?

"The client greets the server and lists supported ciphers; the server responds with its certificate containing its public key; the client verifies that certificate against trusted authorities; then both sides use asymmetric cryptography to securely agree on a shared symmetric session key. From then on, all data is encrypted with that fast session key. It happens once at the start of the connection, on top of the TCP handshake."

Key Points to Remember

ConceptKey Takeaway
HTTPSHTTP + TLS. Encrypted tunnel over the same HTTP. The padlock.
3 guaranteesEncryption (privacy) · integrity (no tampering) · authentication (real server).
Symmetric vs asymmetricSymmetric fast (shared key) · asymmetric solves key exchange (public/private pair).
TLS trickUse asymmetric once to agree a symmetric session key, then symmetric for data.
Certificates/CACA-signed cert proves domain identity → chain of trust → the padlock.

What's Next?

Now that we can make secure HTTP requests, let's design good ones. Chapter 09 covers REST APIs — the conventions for building clean, predictable web APIs that developers love.

Keep learning, keep connecting! See you in the next one!