The Problem

Why HTTP Alone Is Dangerous

HTTP was designed in 1991 for a small academic network. Every packet travels as plain text — readable by anyone sitting between you and the server.

⚠ HTTP

Data sent as raw, readable text
No identity verification of server
Vulnerable to man-in-the-middle attacks
Passwords & credit cards visible on network
Content can be modified in transit

🔒 HTTPS

All data encrypted before transmission
Server identity verified via certificates
Forward secrecy — past sessions stay safe
Tampering detected and blocked
Integrity guaranteed end-to-end

// Packet Sniffer Simulation

AN ATTACKER ON THE SAME NETWORK SEES:

The Building Blocks

Two Types of Encryption

TLS cleverly combines two different cryptographic approaches — using each where it's most effective.

🗝️

Asymmetric Encryption

Uses a public key (anyone can encrypt) and a private key (only you can decrypt). Like a mailbox — anyone drops a letter in, only you can open it.

Used for: TLS handshake, key exchange, digital signatures.

RSA / ECDH / Ed25519

🔑

Symmetric Encryption

Both parties share the same secret key. Much faster than asymmetric — ideal for bulk data after the handshake establishes the shared secret.

Used for: Encrypting all actual HTTP data after handshake.

AES-256-GCM / ChaCha20

Client Hello

Browser

→

Key Exchange
(ECDH)

Asymmetric

→

Session Key
Derived

Shared Secret

→

AES-256
Encryption

Symmetric

→

Secure Data
Transfer

HTTPS

Encryption Playground

Plaintext Input

🔐 →

Encrypted Output

↑ Simplified classical ciphers for illustration. Real TLS uses AES-256-GCM with a 256-bit session key — computationally infeasible to brute-force.

The Magic Moment

The TLS Handshake, Step by Step

Before a single byte of your HTTP request is sent, browser and server perform a cryptographic exchange lasting milliseconds — establishing a shared secret without ever transmitting it.

Key insight: In TLS 1.3, the handshake takes only 1 round-trip (vs 2 in TLS 1.2). Resuming connections can achieve 0-RTT — data sent before handshake completes.

// TLS 1.3 HANDSHAKE SIMULATOR

🌐

BROWSER

🖥️

SERVER

—

Press Start to begin the simulation

Watch how browser and server negotiate a secure session without ever transmitting the secret key.

Trust & Identity

The Certificate Chain of Trust

How do you know the server you're talking to is really google.com? The answer is X.509 certificates — digital documents that bind a public key to an identity, signed by a trusted authority.

CERTIFICATE CHAIN — click each node to inspect

🏛️

Root CA — DigiCert Global Root CA

Self-signed · Trusted by your OS/browser · Valid 25 years

Subject:CN=DigiCert Global Root CA, O=DigiCert Inc, C=US

Issuer:Self-signed (Root)

Public Key:RSA 2048-bit

Valid Until:Nov 10, 2031

Signature Alg:sha256WithRSAEncryption

Fingerprint:A8:98:5D:3A:65:E5:E5:C4:B2:D7:D6:6D:40:C6:DD:2F:B1:9C:54:36

🏢

Intermediate CA — DigiCert TLS RSA SHA256 2020 CA1

Signed by Root CA · Issues leaf certs · Valid 5 years

Subject:CN=DigiCert TLS RSA SHA256 2020 CA1, O=DigiCert Inc, C=US

Issuer:CN=DigiCert Global Root CA

Public Key:RSA 2048-bit

Valid Until:Sep 23, 2030

Key Usage:Certificate Sign, CRL Sign

CA:TRUE (can sign other certs)

🌿

Leaf Certificate — example.com

Signed by Intermediate · Binds domain to public key · Valid 1 year

Subject:CN=example.com, O=Example Corp, L=San Jose, ST=CA, C=US

Issuer:CN=DigiCert TLS RSA SHA256 2020 CA1

Public Key:EC 256-bit (P-256)

SAN:DNS: example.com, DNS: www.example.com

Valid Until:Mar 15, 2026

CA:FALSE (end-entity only)

How validation works: Your browser has ~150 Root CAs pre-installed. It traces the chain upward — each signature verified by the parent's public key — until it hits a trusted root.

Test Your Knowledge

Quick Check

Let's make sure the concepts clicked before you move on.

Key Takeaways

What You Learned

3 Security goals: Confidentiality, Integrity, Authentication

1-RTT TLS 1.3 handshake — half the round-trips of TLS 1.2

256-bit AES session key — 2²⁵⁶ possible keys to brute-force

~150 Root CAs trusted by your browser out of the box

ECDH Key exchange — secure even if private key later leaked (forward secrecy)

mTLS Mutual TLS — both client AND server present certificates (used in APIs)

Further reading: RFC 8446 (TLS 1.3 spec) · Let's Encrypt (free certs) · openssl s_client -connect example.com:443 to inspect any live cert in your terminal.

TLS & HTTPSHow the Web Keeps Secrets

How does data flow through public network securely?

Comments (0)