How HTTPS Actually Works: TLS, Certificates, and Trust

Every time you load a secure site, your browser and the server run a short negotiation that keeps your traffic private and confirms the server is who it claims to be. The result is the padlock in the address bar. The mechanism behind it, TLS, is one of the most important pieces of infrastructure on the internet, and it rests on two ideas from cryptography that are worth understanding even if you never implement them yourself.

Two kinds of keys

Encryption on the web uses two different approaches, and HTTPS needs both.

Symmetric encryption uses a single shared key to both scramble and unscramble data.^[1] It is fast and well suited to encrypting a whole conversation. Its problem is obvious: both sides need the same secret key, and if you have never talked before, there is no safe way to agree on one over a network that an attacker might be watching.

Asymmetric encryption, also called public-key cryptography, solves that.^[2] Each side has a pair of keys: a public key that anyone can see and a private key that stays secret. Something encrypted with the public key can only be decrypted with the matching private key. This lets two strangers establish a shared secret in the open without ever transmitting it directly. The catch is that asymmetric math is slow, too slow to use for an entire conversation.

HTTPS combines them. It uses the slow asymmetric method once, at the start, to agree on a shared secret, then uses fast symmetric encryption with that secret for everything after. You get the safety of public keys and the speed of symmetric keys.

The TLS handshake

The negotiation that sets this up is called the TLS handshake.^[3] In broad strokes, it does three things: it agrees on which cryptographic methods both sides support, it verifies the server's identity, and it establishes the shared symmetric key.

The browser opens by saying hello and listing the cipher suites and TLS versions it understands. The server replies with its choice and sends its certificate, which contains its public key. The two sides then perform a key exchange. Modern TLS uses ephemeral Diffie-Hellman, a method where they derive a shared secret that is never actually sent across the wire, and which is thrown away after the session. That last property is called forward secrecy^[4], and it means that even if the server's private key is stolen later, past recorded sessions cannot be decrypted.

TLS 1.3, the current version released in 2018^[5], streamlined this to a single round trip, and can resume a prior session with zero, which is a large part of why HTTPS stopped being a noticeable performance cost.

Certificates and why you trust them

The key exchange keeps the conversation private, but privacy alone is not enough. If you secretly established a private channel with an attacker pretending to be your bank, the encryption would be perfect and useless. You need proof that the public key really belongs to the site you meant to visit. That proof is the certificate.

A certificate is a document that binds a domain name to a public key.^[6] On its own it proves nothing, because anyone can generate one. What gives it weight is a signature from a Certificate Authority, a trusted organization^[7] whose job is to verify that whoever requested a certificate for example.com actually controls example.com before signing it.

The chain of trust

No single authority signs every certificate directly. Instead there is a chain. Your browser and operating system ship with a built-in list of root certificates^[8] from a small set of trusted authorities. Those roots sign intermediate certificates, and the intermediates sign the certificate your site actually uses.

When the server presents its certificate, your browser follows the chain upward: this certificate was signed by that intermediate, which was signed by a root I already trust. If every link checks out and nothing has expired or been revoked, the browser accepts it. If any link is broken, you get the warning page that tells you the connection is not private. The entire system rests on that preinstalled list of roots, which is why those authorities are held to strict standards and why one misbehaving authority is treated as a serious event.

What the padlock does and does not mean

The padlock is widely misunderstood. It means the connection is encrypted and the site presented a valid certificate for the domain you are visiting. That is genuinely valuable, because it stops anyone between you and the server from reading or tampering with the traffic.

It does not mean the site is safe, honest, or run by who you assume. A scam site can get a valid certificate for its own domain in minutes, and it will show a padlock too. The padlock is a statement about the pipe, not about the person at the other end. Confusing the two is how a lot of people get phished.

Let's Encrypt and HTTPS everywhere

For a long time certificates cost money and took manual effort, so a great deal of the web stayed unencrypted simply out of friction. That changed in 2015 with Let's Encrypt, a nonprofit certificate authority^[9] that issues certificates for free and automatically through a protocol called ACME.^[10] A server can request, install, and renew its certificate with no human involved.

The effect was dramatic. Encrypted traffic went from a minority of the web to the overwhelming majority in a few years.^[11] Browsers pushed in the same direction by marking plain HTTP sites as not secure^[12], and HTTPS shifted from a feature you paid for to the default state of the web.

The whole system is a good example of layered engineering. Fast symmetric encryption carries the data, slow public-key cryptography bootstraps the shared secret, certificates prove identity, a chain of trust reaches back to roots your device already trusts, and free automated issuance made all of it the norm rather than the exception. The padlock is small, but there is a lot of careful design standing behind it.