How HTTPS Works

Every time you visit a website with the padlock icon in your browser, HTTPS is at work. But what actually happens under the hood? This guide walks through every step from the moment you type a URL to when you see a rendered page — focusing on the security layer that protects your data.

What is HTTPS?

HTTPS (Hypertext Transfer Protocol Secure) is the secure version of HTTP. It uses TLS (Transport Layer Security) — the successor to SSL — to encrypt communication between your browser and the web server. This prevents attackers from reading or modifying the data in transit.

HTTPS provides three guarantees:

1. Confidentiality — data is encrypted; eavesdroppers see gibberish
2. Integrity — data cannot be tampered with without detection
3. Authentication — you are talking to the real server, not an imposter

Why HTTPS Matters

Without HTTPS, anyone on the same network (coffee shop Wi-Fi, corporate network, ISP) can:

• Read your passwords, cookies, and form submissions
• Inject ads or malicious scripts into pages you visit
• Impersonate legitimate websites (man-in-the-middle attack)

Google also uses HTTPS as a ranking signal, and browsers now mark HTTP sites as "Not Secure."

Step-by-Step: The TLS 1.3 Handshake

When your browser connects to https://example.com, the following happens:

Step 1: TCP Connection

Before any TLS negotiation, a standard TCP three-way handshake occurs (SYN → SYN-ACK → ACK). This establishes a reliable connection on port 443.

Step 2: Client Hello

The browser sends a ClientHello message containing:

• Supported TLS versions (e.g., TLS 1.3)
• Supported cipher suites (e.g., TLS_AES_256_GCM_SHA384)
• A random number (client random)
• Key share — the client's public key for key exchange (in TLS 1.3, this is sent immediately to save a round trip)

Step 3: Server Hello

The server responds with a ServerHello containing:

• The chosen TLS version and cipher suite
• A random number (server random)
• The server's key share (public key)
• The server's digital certificate

Step 4: Certificate Verification

The browser verifies the server's certificate by checking:

• Certificate chain: Is the certificate signed by a trusted Certificate Authority (CA)?
• Domain match: Does the certificate's Subject Alternative Name (SAN) match the domain?
• Validity period: Is the certificate within its valid date range?
• Revocation status: Has the certificate been revoked? (checked via OCSP or CRL)

If any check fails, the browser shows a security warning.

Step 5: Key Derivation

Both sides now have each other's public key and their own private key. Using the Diffie-Hellman key exchange:

1. Each side computes the shared secret using their private key and the other's public key
2. From the shared secret, both sides derive the same set of symmetric encryption keys
3. These keys are used for all subsequent encrypted communication

This is why it's called a "key exchange" — no key is ever transmitted. Both sides independently compute the same key.

Step 6: Encrypted Communication Begins

The server sends its first encrypted message, which includes:

• The server's Finished message (a hash of all handshake messages so far)
• Optionally, the server can start sending application data immediately (0-RTT in TLS 1.3)

The browser verifies the Finished message, sends its own Finished message, and encrypted application data flows.

TLS 1.3 vs TLS 1.2

Forward Secrecy Explained

Forward secrecy (also called Perfect Forward Secrecy) ensures that even if the server's private key is compromised in the future, past sessions cannot be decrypted. This is because each session uses a unique, ephemeral key pair for the Diffie-Hellman exchange. Once the session ends, the ephemeral keys are discarded.

Certificates and the Chain of Trust

Digital certificates form a chain:

1. End-entity certificate — issued to example.com
2. Intermediate CA certificate — issued by the root CA to a subordinate CA
3. Root CA certificate — pre-installed in your OS/browser (about 150 roots)

The browser walks up the chain, verifying each signature, until it reaches a trusted root. This is the "chain of trust."

Common Misconceptions

• "HTTPS makes my site slower" — TLS 1.3 adds only 1 round trip (about 20-50ms). HTTP/2 and HTTP/3 (which require HTTPS) actually make sites faster.
• "HTTPS means the site is safe" — HTTPS only protects the connection. A phishing site can have a valid certificate.
• "Free certificates are less secure" — Let's Encrypt certificates provide the same encryption as paid certificates.

Summary

HTTPS protects data in transit using TLS encryption. The TLS 1.3 handshake establishes a secure connection in a single round trip by exchanging public keys, verifying the server's certificate, and deriving shared encryption keys. Every production website should use HTTPS — it's fast, free (via Let's Encrypt), and essential for user trust.