TLS/SSL: How HTTPS Actually Works Under the Hood
Series: System Design · Networking & Protocols — Pillar 2 of 8
TLS/SSL: How HTTPS Actually Works Under the Hood
Systems Design
| # | Post | What it covers |
|---|---|---|
| 00 | Networking & Protocols: How Bytes Actually Travel | Before you can design systems that scale, you need to understand how bytes actually travel. Eight concepts every backend engineer must know. (148 chars) |
| 01 | The OSI Model: The Map Every Engineer Needs | The OSI model isn't just interview theory — it's the map that tells you exactly where in the stack a network problem lives. Here's how to use it. (152 chars) |
| 02 | TCP vs UDP: Reliability vs Speed at the Transport Layer | TCP guarantees delivery. UDP doesn't look back. Understanding why each exists — and when to reach for each — is fundamental to network design. (150 chars) |
| 03 | HTTP vs HTTPS: The Language of the Web and Its Secure Version | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 04 | TLS/SSL: How HTTPS Actually Works Under the Hood ← you are here | TLS is what puts the S in HTTPS. Here's how the handshake works, what a certificate actually contains, and why TLS 1.3 matters for performance. (152 chars) |
| 05 | DNS: The Phone Book That Runs the Internet | DNS is the phone book of the internet — and one of the most misunderstood layers in the stack. Here's how it works and how it fails. (133 chars) |
| 06 | DNS Load Balancing: Traffic Distribution at the Name Layer | DNS load balancing distributes traffic before a single packet reaches your servers. Here's how it works, where it excels, and where it falls short. (154 chars) |
| 07 | Anycast Routing: One Address, Everywhere at Once | One IP address, dozens of locations, zero client configuration. Anycast is how the fastest global infrastructure works — here's the mechanism behind it. (158 chars) |
| 08 | CDN: Moving Content Closer to the People Who Need It | A CDN isn't just a cache in front of your server. Here's how content delivery networks work, when they help, and when they add complexity for nothing. (154 chars) |
| 09 | Networking & Protocols: Wrap-Up | A complete recap of the eight core networking concepts — OSI, TCP, HTTP, TLS, DNS, CDN — and how they connect into a complete picture. (135 chars) |
For most engineering purposes, DV certificates — the kind Let's Encrypt issues automatically and for free — are entirely sufficient. The CA verifies you control the domain; that's what clients need to know. OV and EV add identity assurance for human users viewing certificate details, not additional cryptographic security.
TLS termination in system architecture
In production systems, TLS is almost never handled by the application server itself. It's terminated — decrypted — by a dedicated component earlier in the request path:
User ──HTTPS──► Load Balancer / CDN edge ← TLS terminates here
│
│ HTTP (internal network)
▼
Application Server ← sees plaintext HTTP
Why terminate early: TLS decryption is CPU-intensive. Dedicated load balancers (AWS ALB, Nginx, HAProxy) and CDN edge nodes use hardware acceleration for TLS operations. Application servers can focus on application logic rather than cryptographic overhead. Internal traffic between load balancer and application server travels on a private network where plaintext HTTP is acceptable.
The implication for trust: your application server receives plain HTTP. If it needs to know the original connection was HTTPS — for redirect logic, for security headers — it relies on the X-Forwarded-Proto header added by the load balancer. This header can be spoofed if your application server is reachable directly. Ensure your security group or firewall rules prevent direct access to application servers, routing all traffic through the load balancer.
In the URL shortener: TLS terminates at the CDN edge or load balancer. The application server receives a plain HTTP request with X-Forwarded-Proto: https. The redirect response travels back to the edge over HTTP, where it's encrypted for the final leg to the user.
The tradeoffs
TLS 1.2 vs 1.3: TLS 1.2 is still widely supported and not broken, but it's slower (2-RTT handshake vs 1-RTT) and supports cipher suites that are weaker than TLS 1.3's mandatory set. There is no good reason to use TLS 1.2 exclusively for new systems. Supporting TLS 1.2 for backwards compatibility with older clients is reasonable; defaulting to it is not.
Certificate automation vs manual management: Let's Encrypt and ACME-based automation have made manual certificate management largely unnecessary. The operational risk of a certificate expiry causing a production outage is almost entirely eliminated by cert-manager (Kubernetes), AWS Certificate Manager auto-renewal, or certbot with a cron job. The residual risk comes from letting certificates drift out of automation — one certificate managed manually is one certificate that will expire at the worst possible time.
mTLS (Mutual TLS): standard TLS authenticates the server to the client. Mutual TLS authenticates both directions — the client also presents a certificate, and the server verifies it. This is used for service-to-service authentication in microservices architectures (enforced by service meshes like Istio) and for high-security API access. It eliminates the need for API keys or tokens between services — identity is cryptographic. The operational overhead is higher: client certificates must be issued, rotated, and revoked.
The one thing to remember
TLS is not a checkbox — it's a configuration. Having a certificate installed means the connection is encrypted. It does not mean the encryption is fast, the configuration is current, or the implementation is correct. Check your TLS version (1.3 should be the default), verify session resumption is enabled, test your handshake latency on high-RTT connections, and automate certificate renewal before the first expiry teaches you why it matters.
← Previous: HTTP vs HTTPS — the application protocol and what the S adds
→ Next: DNS — TLS authenticates the server once you've connected to it. But how does your client find the right server's IP address in the first place? DNS is the system that answers that question — and its failure modes are some of the most far-reaching in all of infrastructure.
