How HTTPS Works: SSL/TLS Handshake Explained for Frontend Engineers

By Rahul — Google Frontend Engineer

Why Should Frontend Engineers Care About HTTPS?

If you think HTTPS is only a backend concern, think again. Service Workers require HTTPS. Geolocation API requires HTTPS. Clipboard API, Push Notifications, WebAuthn — all require a secure context. Understanding HTTPS is not optional anymore.

HTTP vs HTTPS — The Core Difference

HTTP sends data in plain text. Anyone sitting between the client and server (ISP, public WiFi router, proxy) can read every request and response. HTTPS wraps HTTP inside TLS (Transport Layer Security), encrypting everything.

HTTP:  Client ---[plain text]---> Server
HTTPS: Client ---[encrypted]-----> Server

The TLS Handshake — Step by Step

Before any encrypted data flows, the client and server perform a handshake. Here is the simplified flow:

Step 1: Client Hello

The browser sends a "Client Hello" message containing:

• Supported TLS versions (TLS 1.2, TLS 1.3)
• Supported cipher suites (AES-256-GCM, ChaCha20)
• A random number (Client Random)

Step 2: Server Hello

The server responds with:

• Chosen TLS version and cipher suite
• Server's SSL certificate (contains public key)
• A random number (Server Random)

Step 3: Certificate Verification

The browser checks the certificate against trusted Certificate Authorities (CAs). If verification fails, you see the "Your connection is not private" error.

Step 4: Key Exchange

Using the server's public key, both sides derive a shared session key. In TLS 1.3, this uses Diffie-Hellman key exchange — even if someone records all traffic AND later steals the server's private key, they cannot decrypt past sessions. This is called Forward Secrecy.

Step 5: Encrypted Communication

All subsequent data uses symmetric encryption with the shared session key. Symmetric encryption is fast — the asymmetric part was only for the handshake.

Real-World Production Issues

Mixed Content Blocking

Your page is served over HTTPS but loads an image over HTTP. Browsers block this or show warnings. I have seen this break entire pages when a CMS stored absolute HTTP URLs for images.

// BAD — mixed content
<img src="http://cdn.example.com/photo.jpg" />

// GOOD — protocol-relative or HTTPS
<img src="https://cdn.example.com/photo.jpg" />
<img src="//cdn.example.com/photo.jpg" />

HSTS (HTTP Strict Transport Security)

Once you set this header, the browser will NEVER make an HTTP request to your domain — it upgrades automatically. If you set this and then lose your SSL certificate, your site becomes completely inaccessible.

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

Certificate Pinning Gone Wrong

Some apps pin specific certificates. When the certificate rotates (every 90 days with Let's Encrypt), the app breaks. At Google, we use short-lived certificates and avoid pinning in most cases.

Best Practices

• Always use TLS 1.3 — it is faster (1-RTT handshake vs 2-RTT in TLS 1.2)
• Set up HSTS but start with a short max-age
• Use Content-Security-Policy to prevent mixed content
• Never store sensitive data in URL query parameters — URLs appear in server logs even with HTTPS
• Renew certificates well before expiry. Automate with certbot

Things to Avoid in Production

• Do NOT disable certificate verification in API calls (even in dev)
• Do NOT use self-signed certificates in production
• Do NOT assume HTTPS means the server is trustworthy — it only means the connection is encrypted

Summary

HTTPS is the foundation of modern web security. The TLS handshake establishes trust and creates an encrypted channel. As frontend engineers, we must ensure our apps work correctly in secure contexts and never introduce mixed content vulnerabilities.