The little padlock in your browser is one of the most misunderstood icons on the internet. Users read it as "this site is safe". Many developers read it as "we installed the certificate, security done". Both are wrong, in different ways.

HTTPS is brilliant engineering, and the core ideas fit on a napkin. So let's do this as a set of plain questions, the ones I'd want answered if I were seeing it for the first time.

What problem is HTTPS actually solving?

When your browser talks to a server, the data hops through a lot of machines you don't control: the café Wi-Fi router, your ISP, other networks along the way. Plain HTTP sends everything as readable text, so anyone on that path could do three things:

• Read it (your password, your session cookie)
• Change it (inject ads or malware into the page)
• Pretend to be the server (a fake login page on the real address)

HTTPS (HTTP over TLS) answers all three: privacy through encryption, integrity so changes are detected, and identity so you know you're talking to the real domain.

What's the difference between symmetric and asymmetric keys?

Symmetric encryption uses one shared secret key both to encrypt and to decrypt. It's very fast, which is why it encrypts the actual traffic. The catch: both sides need the same secret, and you can't just send it across the network that you're trying to protect.

Asymmetric encryption uses a pair: a public key you can give to everyone and a private key you never share. My favourite analogy is an open padlock. I can hand out copies of my open padlock to anyone. You put a message in a box and snap my padlock shut. Now only I, with my private key, can open it. Asymmetric keys can also sign things: the server signs with its private key, and anyone can verify the signature with the public key.

Asymmetric crypto is slow, so HTTPS uses each for what it's good at: asymmetric maths to agree on a secret and prove identity, then fast symmetric encryption for the conversation itself.

So what happens in the handshake?

Here's a simplified version of a modern TLS 1.3 handshake:

1. Client hello. The browser says which TLS versions and ciphers it supports and sends its half of a key exchange (a temporary public value).
2. Server hello. The server picks the settings and sends its own half of the key exchange.
3. Shared secret. Using a clever bit of maths (Diffie-Hellman key exchange), both sides now compute the same secret, even though that secret never travelled across the wire.
4. Proof of identity. The server sends its certificate and signs the handshake with its private key. The browser checks the certificate and the signature.
5. Encrypted traffic. From here, everything uses fast symmetric keys derived from the shared secret.

A nice property of using fresh, temporary keys for every session is forward secrecy: even if someone steals the server's private key next year, they can't decrypt traffic they recorded today.

What does the certificate authority actually prove?

Here's the weak spot in the plan: when the server sends its public key, how do you know it's really the server's key and not an attacker's?

That's the job of the certificate. A certificate says "this public key belongs to example.com", and it's signed by a certificate authority (CA). Your browser and operating system ship with a list of CAs they trust. If the signature chain leads back to one of them, and the domain matches, and the certificate hasn't expired, the browser accepts it.

But notice what a typical certificate proves: control of the domain. Services like Let's Encrypt verify that you can serve a file or set a DNS record for that domain, then issue the certificate automatically. That's great for getting the whole web onto HTTPS. It does not mean anyone checked whether the business behind the site is honest.

What does HTTPS NOT protect?

This is the part I most want developers to remember.

• It doesn't make the site trustworthy. Phishing sites use HTTPS too. A lookalike domain such as yourbank-secure-login.com can have a perfectly valid padlock.
• It doesn't hide which site you visit. The full URL path and the page content are encrypted, but the domain name usually leaks through DNS lookups and the TLS handshake itself, and the server's IP address is always visible.
• It doesn't fix your application bugs. SQL injection, XSS, broken access control: all of these travel happily through an encrypted tunnel. The attacker's request is encrypted too.
• It doesn't protect data at rest. Once the request reaches your server, it's plain data in your logs, database and backups. Encrypting those is a separate job.
• It doesn't protect a compromised device. Malware on the user's machine sees everything before it gets encrypted.

HTTPS protects the road between two points. It says nothing about what happens at either end.

What should I actually do as a developer?

• Redirect all HTTP to HTTPS, and send an HSTS header (Strict-Transport-Security) so browsers stop trying plain HTTP at all. Start with a short max-age and increase it once you're sure every subdomain works over HTTPS.
• Mark cookies Secure so they're never sent over plain HTTP. In Laravel, set SESSION_SECURE_COOKIE=true.
• Automate renewal. An expired certificate takes your site down as effectively as a crashed server. Certbot or your cloud provider's managed certificates make this boring, which is what you want.
• Behind a load balancer? TLS often ends at the load balancer, and your app receives plain HTTP. Configure trusted proxies so the framework knows the original request was HTTPS, otherwise you'll get mysterious redirect loops and http:// links in generated URLs.
• Turn off old TLS versions (1.0 and 1.1) where you control the server config.

If you want to see a certificate chain for yourself, click the padlock in your browser and open the certificate details. Following the chain up to the root once makes the whole CA idea click.

The takeaway

The padlock means three things: nobody on the path can read the traffic, nobody can change it unnoticed, and the server controls the domain in the address bar. That's a lot, and it's a baseline every site should have.

It doesn't mean the site is safe, the code is secure, or the data is protected once it arrives. Those are still our job.

When you explain HTTPS to someone non-technical, what analogy do you use? I'm always collecting better ones than the padlock box.