The padlock icon in your browser has become shorthand for “safe.” It means so little that phishing sites now use it routinely. Google’s Transparency Report has shown that HTTPS adoption is near-universal across the web, yet breaches keep happening. The certificate, the thing everyone points to, is the least interesting part of the story. Here is what actually protects your data.
1. The Certificate Proves Identity, Nothing Else
A TLS certificate does one job: it tells your browser that the server you’re talking to is who it claims to be. A certificate authority (a company like DigiCert or Let’s Encrypt) has cryptographically signed a statement saying “this public key belongs to bank.com.” Your browser checks that signature against a pre-installed list of trusted authorities.
That’s it. The certificate doesn’t encrypt your data. It doesn’t prevent the server on the other end from mishandling what you send. It doesn’t protect against a compromised certificate authority, which has happened, most notably when Dutch CA DigiNotar was breached in 2011 and attackers issued fraudulent certificates for Google domains. Identity verification is necessary but nowhere near sufficient.
2. The Handshake Is Where the Real Negotiation Happens
Before a single byte of your actual request travels across the network, your browser and the server run through a handshake protocol. They agree on which cipher suite to use, exchange key material, and derive a shared secret that neither side ever transmits directly. This is the TLS handshake, and it’s doing the substantive work.
The modern version (TLS 1.3, finalized in 2018) cut the handshake from two round trips to one, which matters for performance, but more importantly it eliminated a menu of legacy algorithms that had accumulated decades of known weaknesses. Older versions allowed negotiation down to cipher suites with 40-bit export-grade encryption, a deliberate weakening the U.S. government required in the 1990s. The FREAK and Logjam attacks in 2015 showed that servers still supporting those suites could be exploited years later. Protocol version matters more than the presence of a certificate.
3. Forward Secrecy Protects You From Your Future Self
Classic key exchange had a catastrophic property: if an attacker recorded your encrypted traffic today and later obtained the server’s private key, they could decrypt everything retroactively. Intelligence agencies are known to operate on exactly this model, storing encrypted traffic in bulk for future decryption.
Forward secrecy, technically called Perfect Forward Secrecy (PFS), solves this by generating a fresh, ephemeral key pair for each session. The session key is derived, used, and discarded. Compromising the server’s long-term private key later gives an attacker nothing they can use against past sessions. TLS 1.3 makes forward secrecy mandatory. Earlier protocol versions made it optional, and many servers never bothered to enable it. If you were using a service in 2013 that hadn’t implemented PFS, your traffic from that period is potentially vulnerable to anyone who stored it.
4. Symmetric Encryption Does the Heavy Lifting
Once the handshake establishes a shared secret, asymmetric cryptography steps aside. Encrypting actual data with RSA or elliptic curve algorithms is computationally expensive. Instead, both sides derive a symmetric key (typically used with AES-GCM) and that’s what actually scrambles your messages in transit.
AES-GCM deserves a moment of attention because it provides both confidentiality and authenticity simultaneously. It encrypts your data and produces an authentication tag that lets the receiver verify the ciphertext hasn’t been tampered with. An attacker who intercepts and modifies your encrypted traffic won’t just fail to read it; the modification will be detected and the connection will fail. This is authenticated encryption, and it closes an attack class that purely confidential ciphers left open.
5. Certificate Transparency Catches Misissuance, Eventually
Certificate authorities can make mistakes or be compromised. The solution the industry settled on is Certificate Transparency (CT), a public, append-only log of every certificate issued. Browsers now require that certificates be logged before they’ll trust them. Domain owners can monitor these logs for unauthorized certificates issued for their domains.
This doesn’t prevent misissuance. It makes misissuance detectable and attributable after the fact. It’s an auditing mechanism, not a prevention mechanism. Google’s own infrastructure team discovered several unauthorized certificates for Google domains through CT monitoring. The system works, but it works on the timescale of detection and revocation, not the timescale of a real-time attack.
6. The Weakest Link Is Almost Never the Encryption
Modern TLS, implemented correctly, is not where breaches happen. Attackers don’t break AES-128. They find an unpatched application vulnerability and extract data from the database directly. They compromise a developer’s credentials. They find an API endpoint that authenticates but doesn’t authorize. The data that leaves your browser protected by TLS arrives at a server and gets written somewhere. That somewhere is usually where it goes wrong.
The lesson here isn’t that HTTPS is pointless. Unencrypted traffic is trivially intercepted on shared networks, and the protections described above are real. The lesson is that the padlock is the beginning of a security story, not the end of one. Treating certificate presence as a security guarantee is a category error that has cost real organizations real money. Understanding what the protocol actually does, and where its responsibility ends, is the only way to reason honestly about what’s protected and what isn’t.
