How HTTPS Actually Works: TLS, Certificates, and What the Padlock Really Means

You have seen the little padlock in your browser's address bar thousands of times. Most people know it means "secure" and leave it there. But if you asked a room full of people what the padlock actually proves, almost nobody could tell you, and a fair few would give you an answer that is comfortingly wrong. That gap matters, because scammers depend on it every single day.

So let us close the gap. This is a friendly, unhurried tour of what really happens in the split second between typing an address and seeing the page appear. We will follow the conversation your browser has with the server, see how a certificate proves you are talking to the real thing, and finish with the single most important lesson of all: what that little padlock does, and just as crucially, does not, tell you. Along the way you will pick up the core ideas behind almost all secure communication on the internet.

HTTPS is just HTTP inside a secure tunnel

Let us start with the letters. HTTP is the language browsers and servers use to ask for and send web pages. The trouble is that plain HTTP sends everything in the clear, like shouting across a crowded room. Anyone positioned between you and the server can listen in and even change what passes by. That "anyone" is not paranoid fantasy: it includes whoever runs the coffee shop WiFi you are on, your internet provider, and anyone who has quietly inserted themselves somewhere along the path your data travels. On plain HTTP they can read your messages, your logins, everything, and rewrite them too.

HTTPS fixes this by wrapping that same ordinary HTTP inside a protective tunnel called TLS, which stands for Transport Layer Security. TLS is the technology doing the real work behind the padlock. Think of the difference like this: plain HTTP is a postcard that every postal worker along the way can read, while HTTPS is that same message sealed inside an armoured tube that only the intended recipient can open. TLS gives you three distinct protections.

• Confidentiality: nobody in the middle can read the traffic. It is scrambled into gibberish for anyone without the key.
• Integrity: nobody can tamper with the traffic without being detected. If a single byte is altered in transit, both ends notice.
• Authentication: you can be sure you are actually talking to the real server for the domain you asked for, not an impostor sitting in the middle.

That third protection is the one people overlook, and it is where certificates come in. Encryption alone would be useless if you could not be sure who was on the other end of the tunnel. These three guarantees, confidentiality, integrity, and authentication, are the same trio that runs through all of cryptography, explained more fully in what is cryptography.

The handshake, step by step

When you connect to an HTTPS site, your browser and the server run a quick opening negotiation called the TLS handshake. It happens in a fraction of a second before any page content moves. In modern TLS version 1.3, which most of the web now uses, it is fast and streamlined, and it looks roughly like this.

1. Browser: "Hello. Here are the ciphers I support and my key share."
2. Server: "Hello. We'll use this cipher, here's my key share,
            and here's my certificate proving I am example.com."
3. Both sides derive the same shared secret from the key shares.
4. Everything after this is encrypted with that shared secret.

Let us unpack the jargon gently. A cipher is simply an agreed method for scrambling and unscrambling data, and both sides need to pick one they both understand. A key share is a piece of mathematical information each side sends so that, combined with a secret each keeps to itself, they can both arrive at the same shared secret. The clever bit is step three. Using a branch of maths called asymmetric cryptography, where a public key and a private key work together as a matched pair, the two sides can agree on a shared secret out in the open without ever actually transmitting that secret. An eavesdropper watching every message go by still cannot work it out. From that point on they switch to fast symmetric encryption, where the same shared secret both locks and unlocks the data, to protect the actual page contents.

Modern handshakes go one step further and use ephemeral keys, meaning the key material for agreeing the shared secret is freshly generated for each session and thrown away afterwards. This gives a valuable property called forward secrecy. Suppose an attacker records your encrypted session today and, years later, somehow steals the server's long term private key. With forward secrecy, those old recorded sessions still cannot be decrypted, because each conversation used its own throwaway secret that no longer exists anywhere. Yesterday's secrets stay secret even if tomorrow's keys are compromised.

How a certificate proves identity

Here is a subtle trap. Encryption on its own is not enough, because you could set up a perfectly encrypted, perfectly private conversation with a complete impostor. A secure tunnel to the wrong person is worse than useless, since it feels safe while it is not. This is the exact problem the certificate solves. The certificate is what proves the server really is who it claims to be before you trust the tunnel.

A certificate is essentially a signed statement that says "the public key below belongs to example.com". The signature comes from a Certificate Authority, usually shortened to CA, which is an organisation your browser and device already trust to vouch for identities. Your device ships from the factory with a built in list of trusted root CAs, a bit like a list of notaries whose stamp you accept without question. Because a root CA does not sign every website directly, trust is passed down a chain.

Root CA (trusted by your device)
   signs -> Intermediate CA
              signs -> example.com's certificate

Each link vouches for the next, all the way down to the individual website. This chain of signatures is what lets your browser trust a site it has never seen before: it does not need to know example.com in advance, it only needs to trust the root at the top of the chain, and follow the signatures down. The signing itself relies on digital signatures, the same private key stamping mechanism covered in what is cryptography.

When the server presents its certificate during the handshake, your browser quietly runs a series of checks:

• Does the name on the certificate match the site you actually asked for?
• Is it still within its valid dates, and not expired?
• Does it chain up through intermediates to a root CA your device trusts?
• Has it been revoked, meaning cancelled early because something went wrong?

If any single check fails, you get the scary full page warning that tells you to turn back. If they all pass, you get the padlock and the page loads. All of this happens in the blink of an eye, every time.

What the padlock does not mean

Now for the part worth burning into memory, because this is where so much harm happens. The padlock means two specific things and no more: the connection is encrypted, and the certificate is valid for the domain shown in the address bar. It does not mean the website is honest, safe, or run by trustworthy people. It vouches for the pipe, not for the person at the other end of it.

Put plainly, the padlock answers the question "is my connection to this domain private and untampered with?" It does not answer the very different question "should I trust this domain at all?" Confusing those two questions is the heart of most phishing, and simply knowing they are different questions already puts you ahead of most people.

The takeaway

HTTPS gives you a private, tamper evident channel to a server whose identity has been vouched for by a Certificate Authority. That is genuinely a lot, and it is worth insisting on everywhere, on every site, without exception. The TLS handshake sets up a shared secret using slow asymmetric cryptography, then switches to fast symmetric encryption for the actual traffic, with ephemeral keys giving forward secrecy so past sessions stay safe even if a key leaks later. The certificate, backed by a chain of trust up to a root CA, is what proves you reached the real server and not an impostor.

Just remember the exact boundary of the promise. HTTPS secures the road, it does not vet the destination. The padlock confirms a private, verified connection to a domain, and nothing about the character of whoever owns that domain. Always check the actual domain name yourself, because the padlock never will.

If you enjoy this way of thinking about what a security control actually protects, the same clear eyed lens applies to encryption at rest in what full disk encryption really protects you from.