How HTTPS/SSL Works

In 1994, the web was mostly text and links. Then Netscape released a browser feature that let people type credit card numbers into a webpage without anyone intercepting them. The protocol was called SSL, and it solved a problem that had stopped the internet from becoming a place where real commerce could happen: how do you have a private conversation with a stranger you’ve never met, over a network you don’t control, without knowing in advance what key to use?

The short answer

HTTPS (Hypertext Transfer Protocol Secure) is the encrypted version of HTTP, the protocol that transfers data between your browser and websites. HTTPS works by running HTTP inside a layer called TLS (Transport Layer Security), which encrypts data in transit so that only your browser and the target server can read it. When you see the padlock icon in your address bar, your browser and the server have completed a cryptographic handshake, established a shared encryption key, and agreed to keep that channel private.

The full picture

The problem with plain HTTP

Before HTTPS, all web traffic traveled as plaintext. That meant every router, ISP, and network device between you and the server could read exactly what you were sending and receiving. On a coffee shop Wi-Fi network, someone with basic tools could watch every page you visited, every form you filled out, every login credential you typed.

This wasn’t theoretical. The attack is called a man-in-the-middle, and it requires nothing exotic: just software freely available online and proximity to your network. Plain HTTP offered no defense at all, because neither your browser nor the server had any way to know whether the data had been tampered with or observed in transit.

HTTPS was designed to solve three things at once: confidentiality (no one can read the data), integrity (no one can alter it), and authentication (you’re actually talking to who you think you are).

The TLS handshake, step by step

The magic happens before you see any content. When your browser connects to an HTTPS site, it initiates a process called the TLS handshake. Think of it as two strangers agreeing on a secret language before they start talking, in full view of anyone who might be listening.

Here’s what happens in roughly the first 100 milliseconds:

1. Client hello. Your browser opens the conversation by sending the server a list of TLS versions it supports, the cryptographic methods it can use, and a randomly generated number.

2. Server hello. The server picks the best mutually supported options, sends back its own random number, and attaches its digital certificate.

3. Certificate verification. Your browser inspects the certificate. Is it issued by a trusted authority? Is it valid today? Does the domain name match? If any check fails, the browser throws a warning and stops.

4. Key exchange. Both sides use the two random numbers plus an additional value to independently derive the same encryption key. This is done using asymmetric cryptography, meaning the key itself never actually travels across the connection. Both sides arrive at it through math.

5. Finished. Both browser and server send a quick “ready” message encrypted with the new key, confirming that everything worked. From this point on, all data flows through symmetric encryption using the shared key.

The whole handshake takes milliseconds. You never see it. But every HTTPS connection starts here.

How both sides end up with the same key without sharing it

This is the part that surprises most people. At step four above, how can two parties arrive at the same secret key without ever sending that key to each other? The answer is a piece of mathematics called the Diffie-Hellman key exchange, published in 1976.

The intuition goes like this: imagine you and a stranger want to agree on a secret color of paint, but you have to talk in a room full of people. You both start with the same public color, say yellow. You each secretly mix in your own private color. You swap your mixed colors with each other. Each of you then adds your own private color to what you received. You both end up with the same final mixture, but no one watching could figure it out without knowing at least one of the private colors.

In practice, this uses modular arithmetic on very large prime numbers instead of paint. The math is easy in one direction (mixing) and effectively impossible to reverse (un-mixing), which is what makes it secure. The National Institute of Standards and Technology sets the minimum key sizes that are considered safe.

What certificates actually do

A certificate is an identity document for a server. It contains the server’s public key, the domain name it’s valid for, an expiration date, and a digital signature from a certificate authority.

Certificate authorities are organizations whose job is to verify that a domain is operated by who it claims to be. Browsers ship with a built-in list of around 150 trusted certificate authorities. When a browser encounters a certificate signed by one of these authorities, it trusts that the server is legitimate. When the signing authority is unknown or the certificate is self-signed, the browser warns you.

This system has a meaningful flaw: it relies on every trusted certificate authority being competent and honest. In 2011, a Dutch certificate authority called DigiNotar was hacked. The attackers used it to issue fraudulent certificates for Google, Yahoo, and dozens of other major domains, meaning they could have intercepted traffic from anyone connecting to those sites. DigiNotar was subsequently removed from browser trust lists and went bankrupt within weeks. The incident prompted the creation of Certificate Transparency, a public log of all issued certificates that anyone can audit.

HTTP/2, HTTP/3, and why HTTPS got faster

A common complaint about HTTPS in its early years was that it added latency. Setting up encryption takes extra round trips, and extra round trips add time. This complaint is largely obsolete.

TLS 1.3, released in 2018, reduced the handshake from two round trips to one. Session resumption lets returning visitors skip most of the handshake entirely. And HTTP/2 (which requires HTTPS in practice) introduced request multiplexing, meaning a single connection can handle dozens of requests simultaneously instead of queuing them up.

The result is that HTTPS sites are often faster than their HTTP equivalents today, because the modern protocol stack was designed around encryption from the start.

The difference between TLS and SSL

SSL (Secure Sockets Layer) was Netscape’s original protocol, released in 1995. It was succeeded by TLS 1.0 in 1999, then TLS 1.1, 1.2, and 1.3. SSL 3.0 was officially deprecated by the Internet Engineering Task Force in 2015 after a vulnerability called POODLE made it exploitable.

If you’re running SSL 3.0 today, you have bigger problems than nomenclature. Every modern server and browser uses TLS. The word “SSL” persists in the language because it was the original name people learned. When your web host sells you an “SSL certificate,” you’re getting a TLS certificate.

Why it matters

HTTPS protects against two separate threats that most people conflate: surveillance and tampering.

The surveillance threat is obvious: without encryption, your ISP, your employer, your government, and any attacker on your network can read your traffic. This is not theoretical. Major ISPs have injected ads into unencrypted web traffic. HTTP Observatory data from Mozilla shows that as of 2024, over 90% of web pages loaded in Firefox use HTTPS, up from below 40% in 2015.

The tampering threat is less obvious but equally serious. Without integrity protection, a network device between you and a server can modify what you receive: swap out links, inject malware into downloaded files, or change the content of a webpage to serve different ads. HTTPS guarantees that what you receive is exactly what the server sent, bit for bit.

There’s also the authentication angle. When you type your bank’s URL and see the padlock, you know you’re connected to a server holding the private key that corresponds to a certificate your bank registered with a trusted authority. It’s not a guarantee that the bank’s software is secure, but it is a guarantee you’re talking to the right server, not an impostor.

Common misconceptions

“The padlock means the site is safe.” The padlock means the connection is encrypted. It says nothing about whether the site itself is legitimate, trustworthy, or free from malware. Phishing sites routinely use HTTPS. Look for the padlock as a minimum baseline, not a verdict on the site.

“HTTPS slows down websites.” This was true in the early 2000s when TLS negotiation added noticeable overhead on dial-up and early broadband. Modern TLS 1.3 has cut handshake time dramatically, and HTTP/2 (which is bundled with HTTPS in practice) more than compensates through multiplexing and compression. Google’s own infrastructure team has measured HTTPS as adding negligible latency at scale.

“If you’re not buying anything, you don’t need HTTPS.” Any site that accepts logins, serves personalized content, or handles form inputs benefits from HTTPS. Beyond that, even a static news site benefits: without HTTPS, your ISP can see every article you read. Reading habits are personal data too.