AlgoInsight

System Design

How HTTPS and TLS Work

The padlock in your browser represents a genuinely elegant piece of cryptography. Here's how HTTPS and TLS actually secure a connection - encryption, authentication, and the handshake that sets it all up - explained without the math.

By Admin2026-06-1815 min readhttpstlssslsecurityencryptionnetworking

That padlock icon in your browser's address bar represents one of the most important and elegant pieces of engineering on the internet. It means your connection is secured by HTTPS - and underneath it, by TLS - so that the data you exchange with a website can't be read or tampered with by anyone in between, and you know you're really talking to who you think you are. Most engineers know "HTTPS is the secure version of HTTP" without knowing how it actually works. This guide explains the real mechanism - encryption, authentication, and the handshake that sets it up - without drowning in the cryptographic math.

What HTTPS is, and what it protects

HTTPS is simply HTTP running over TLS (Transport Layer Security). HTTP carries the web's requests and responses; TLS wraps that traffic in security. So HTTPS = HTTP + TLS. (You'll sometimes hear "SSL" - that's TLS's predecessor; people often say SSL but mean TLS, which replaced it.)

TLS provides three guarantees, and it's worth being precise about all three because they're distinct:

Without these, everything you send over the web - passwords, messages, payments - would travel in the open, readable and alterable by anyone on the network path. TLS is what makes the web safe to transact on, and it's the reason you can use a coffee-shop Wi-Fi network to check your bank balance without the person at the next table being able to read it.

The core idea: two kinds of cryptography

To understand TLS, you need one key idea: it uses two kinds of encryption together, because each solves a different problem.

TLS combines them cleverly: it uses asymmetric encryption to securely establish a shared symmetric key, and then uses fast symmetric encryption with that key for the actual data of the session. You get the security of asymmetric (to set up the secret safely) and the speed of symmetric (for the bulk of the data). This combination is the heart of how TLS works.

Certificates and the chain of trust

There's still the authentication problem: how do you know the public key you received actually belongs to the real website, and not an impostor who handed you their own key? The answer is certificates and Certificate Authorities (CAs).

A website's TLS certificate contains its public key and identity (its domain), and crucially, it's digitally signed by a Certificate Authority - a trusted third party. Your browser (and operating system) come with a built-in list of trusted CAs. When a server presents its certificate, your browser checks that it's signed by a CA it trusts. Because the CA verified the site's identity before signing, that signature is a vouching: "this public key really does belong to this domain."

This creates a chain of trust: you trust your browser's built-in CAs, the CAs vouch for websites by signing their certificates, and so you can trust a website's certificate (and thus its public key) even though you've never encountered it before. If a certificate is missing, expired, or not signed by a trusted CA, your browser warns you - which is exactly the protection against impostors. The certificate system is what turns "here's a public key" into "here's a public key you can trust belongs to this site."

The TLS handshake, step by step

Now put it together. When you connect to an HTTPS site, before any actual data is exchanged, a TLS handshake sets up the secure connection. Roughly:

  1. Client hello. Your browser contacts the server, announcing it wants a secure connection and which encryption methods it supports.
  2. Server hello + certificate. The server responds, agreeing on the encryption method, and sends its certificate (containing its public key, signed by a CA).
  3. Authentication. Your browser verifies the certificate - checking it's signed by a trusted CA, is for the right domain, and isn't expired. This confirms the server's identity. (If verification fails, you get the scary warning.)
  4. Key exchange. Using asymmetric cryptography (the server's public key from the certificate), the two sides securely establish a shared symmetric session key - without ever sending it in the clear where an eavesdropper could grab it.
  5. Secure session. From here, both sides use that fast symmetric key to encrypt all the actual data. The connection is now confidential, integrity-protected, and authenticated.

After the handshake, the encrypted HTTP traffic flows - this is HTTPS. The handshake happens once at the start (adding a little latency, which is part of why connection setup matters and why HTTP/3 works to speed it up), and then the session proceeds securely.

sequenceDiagram
    participant C as Browser
    participant S as Server
    C->>S: Client hello (supported ciphers)
    S-->>C: Server hello + certificate (public key, CA-signed)
    C->>C: Verify certificate against trusted CAs
    C->>S: Securely establish shared session key (using server's public key)
    Note over C,S: Both now share a symmetric session key
    C->>S: Encrypted data (fast symmetric encryption)
    S-->>C: Encrypted data

This sequence diagram shows the TLS handshake. The browser sends a client hello listing supported encryption methods. The server responds with a server hello and its certificate, which contains its public key and is signed by a Certificate Authority. The browser verifies the certificate against its trusted CAs to confirm the server's identity. Then, using the server's public key, the two sides securely establish a shared symmetric session key without sending it in the clear. From that point, all data is encrypted with the fast symmetric key. The handshake sets up a confidential, authenticated, integrity-protected connection.

What's actually in a certificate

Since certificates are central to TLS's authentication, it helps to know what one contains. A TLS certificate includes: the domain name(s) it's valid for, the public key of the server, the identity of the holder, the issuing CA, a validity period (certificates expire and must be renewed), and the CA's digital signature vouching for all of it. When your browser receives it, it checks all of these - right domain, not expired, signed by a trusted CA.

Certificates also come in different validation levels. Domain-validated certificates just prove control of the domain (the most common, often free and automated now). Organization-validated and extended-validation certificates involve more verification of the organization behind the site. For most purposes, a domain-validated certificate is what secures a connection, and automated certificate issuance has made getting one fast and free - a big reason HTTPS is now nearly universal rather than a premium feature.

Forward secrecy: protecting past sessions

A more advanced property worth knowing: forward secrecy. Modern TLS is designed so that even if the server's long-term private key is later compromised, past recorded sessions can't be decrypted. This works because session keys are generated fresh for each session in a way that isn't simply recoverable from the server's main private key. So an attacker who records your encrypted traffic today and steals the server's key a year from now still can't decrypt that recorded traffic. Forward secrecy means a key compromise doesn't retroactively expose all past communications - each session's secrecy stands on its own. It's a standard feature of modern TLS and the kind of detail that signals understanding beyond the basics.

TLS termination: where decryption happens

TLS doesn't have to be handled by your application servers directly. Often, TLS termination happens at a load balancer, reverse proxy, or CDN edge in front of your servers - that component handles the TLS handshake and decryption, then passes the decrypted request to your backend over the internal network. This offloads the cryptographic work from application servers and centralizes certificate management in one place.

This is why, in system design, you'll often see TLS terminated at the edge (the CDN or load balancer): it's efficient (crypto work concentrated and optimized there), it simplifies certificate management (one place rather than every server), and for CDNs it means the secure handshake happens close to the user (faster). Knowing that TLS termination is typically an edge/load-balancer concern, not something every application server handles, is useful real-world architecture understanding.

Common certificate errors and what they mean

The browser warnings map directly to TLS's checks:

Each warning corresponds to one of TLS's verification steps - and each is the system correctly refusing to establish a "secure" connection it can't actually verify. Understanding the errors is understanding TLS's authentication checks from the failure side.

A note on SSL, TLS, and versions

A point of terminology: people say "SSL" constantly, but SSL (Secure Sockets Layer) is the old, deprecated predecessor of TLS. SSL had known vulnerabilities and is no longer used; TLS replaced it. So "SSL certificate" or "SSL connection" almost always means TLS - the name just stuck culturally. TLS itself has versions, with older ones (TLS 1.0, 1.1) now deprecated and modern connections using TLS 1.2 and the newer, faster TLS 1.3 (which streamlined the handshake to fewer round-trips and removed older insecure options).

The practical upshot: use modern TLS (1.2 or 1.3), don't use deprecated SSL or early TLS versions, and understand that "SSL" in casual speech means TLS. Staying current matters because security protocols are an arms race - older versions accumulate known weaknesses, so the recommendation is always to use current versions and retire the old. This is the same "keep it current" discipline that runs through all of security.

Why HTTPS is now the default everywhere

It's worth noting how thoroughly HTTPS has become the norm, because it reflects the security reasoning above. A decade ago, many sites used plain HTTP and reserved HTTPS for login and payment pages. Today, HTTPS is effectively universal - browsers mark plain HTTP sites as "not secure," search engines favor HTTPS, and automated, free certificate issuance removed the cost and effort barrier that once made HTTPS a chore.

The reasoning behind this shift is sound: any unencrypted traffic is readable and tamperable by anyone on the network path, not just the obviously-sensitive pages. An attacker on the same network can read what you browse, inject content into unencrypted pages, or tamper with downloads. There's no longer a good argument for leaving any traffic unencrypted - the cost is near zero and the protection is real. So the industry moved to "encrypt everything," and TLS is what makes that practical at scale. Understanding why the web went all-in on HTTPS - that partial encryption left too much exposed, and the barriers to full encryption fell away - rounds out understanding what TLS provides and why it matters for every connection, not just the sensitive ones.

Why this design is clever

It's worth appreciating why TLS is built this way, because each piece solves a specific problem:

Each tool covers another's weakness. Asymmetric handles the secure setup that symmetric can't; symmetric handles the fast bulk encryption that asymmetric would be too slow for; certificates handle the trust that raw key exchange lacks. The result is a connection that's confidential, authenticated, and integrity-protected, established efficiently. That elegant composition is what the padlock represents.

Interview: HTTPS and TLS come up in system design around security. The strong answer: HTTPS is HTTP over TLS, which provides encryption, integrity, and authentication. The mechanism worth explaining: TLS uses asymmetric cryptography to securely establish a shared symmetric key, then uses fast symmetric encryption for the session data, and uses CA-signed certificates so you can trust the server's identity. Knowing why both kinds of crypto are used (asymmetric for secure setup, symmetric for fast bulk encryption) and what certificates provide (the chain of trust against impostors) signals real security understanding beyond "HTTPS is encrypted."

The bottom line

HTTPS is HTTP secured by TLS, providing three guarantees: encryption (confidentiality), integrity (tamper-detection), and authentication (you're talking to the real server). TLS achieves this by combining two kinds of cryptography - slow asymmetric encryption to securely establish a shared key over an insecure channel, then fast symmetric encryption with that key for the actual data - and by using CA-signed certificates to create a chain of trust that proves the server's identity. The TLS handshake sets all this up at the start of a connection: hello, certificate, verification, key exchange, then a secure encrypted session.

The padlock represents this whole elegant composition - each cryptographic tool covering another's weakness to make the web safe to transact on. Understand the handshake and the two-crypto design, and HTTPS stops being magic. We cover web security and TLS across System Design Fundamentals.

Go deeper

More articles