Asymmetric keys, certificate chains, the handshake — what the padlock actually means, and the surprising amount it doesn't protect you from.
You've been told to look for the padlock. "If there's a padlock it's safe." That's half-true at best, and understanding the half that's missing will make you meaningfully smarter about security than most people — including most developers who just use HTTPS without understanding what it's actually doing.
Let's start from the ground up.
The internet is a public network. Data passes through dozens of routers, switches, and cables on the way from your device to any server. Any of those could be controlled by someone hostile. How do you have a private conversation when the channel is inherently public?
The naive answer is: encrypt the data. But encryption requires a key. If you want to share a key with a server you've never talked to, you have to send that key over the same insecure network — and anyone watching could intercept it. This is called the key exchange problem, and it stumped cryptographers for most of history.
In the 1970s, Diffie, Hellman, Rivest, Shamir, and Adleman independently developed public-key cryptography. The insight: instead of one shared secret key, use a mathematically linked pair of keys. What one encrypts, only the other can decrypt.
This solves the key exchange problem. The server publishes its public key openly. You encrypt with it. Only the server — holding the matching private key — can read what you sent. An eavesdropper sees only encrypted ciphertext.
Think of the public key as a mailbox slot — anyone can drop a message in. The private key is the key to open the mailbox — only the owner has it. You can publish your mailbox address (public key) everywhere without risk. The messages inside are private because only you can open the box.
But there's a catch. Asymmetric encryption is computationally expensive — roughly 1,000 times slower than symmetric encryption. You can't use it to encrypt a video stream. So in practice, TLS uses asymmetric cryptography only to securely exchange a session key — a random symmetric key generated fresh for that one connection. All the actual data flows under that fast symmetric key (AES). The asymmetric crypto is used only for the handshake. As Steve Gibson explains: "You choose a random number to generate the key. Then you encrypt the bulk of the message very quickly with the key. Then you use the public key technology to only encrypt the key, not the message." — Security Now! #34
TLS — Transport Layer Security — is the protocol that implements this for the web. It replaced the older SSL protocol (which you'll still hear about, but SSL is retired and broken). When people say "SSL certificate" they mean a TLS certificate; the names stuck even though SSL is gone.
HTTPS is simply HTTP running over a TLS connection. Everything you send and receive — URL paths, headers, cookies, request body, response body — is encrypted. The only thing visible to an observer is the destination IP address and (usually) the server hostname via SNI.
Asymmetric cryptography solves eavesdropping. But it doesn't solve a different problem: how do you know the public key actually belongs to the server you think you're talking to?
Anyone can generate a key pair. A malicious server could present a valid-looking public key and you'd have no way to know it wasn't really Google, or your bank. This is the identity problem — and it's solved by certificates.
A TLS certificate is a document that says: "This public key belongs to this domain name, and I — a trusted Certificate Authority — am vouching for that."
A Certificate Authority (CA) is an organization that has verified a domain owner's identity and signed their certificate with the CA's own private key. Your browser and OS come pre-loaded with a list of trusted CAs (roughly 150 of them). When a server presents a certificate signed by one of those trusted CAs, your browser accepts it.
In practice, CAs don't sign your certificate directly with their root key (that would be catastrophic if the root key were ever compromised). They use an intermediate structure:
Your browser validates the chain: "Does the root CA trust this intermediate? Does the intermediate trust this domain cert? Is the domain cert for the hostname I requested? Is it expired? Is it revoked?" Only when all checks pass does the connection proceed.
Before any encrypted data flows, the client and server negotiate a TLS connection. TLS 1.3 (current) streamlines this to a single round-trip:
TLS 1.2 (old) required two round-trips to establish a connection and supported a bunch of weak cipher suites that enabled various attacks. TLS 1.3 cuts to one round-trip, removes all the weak options, and mandates forward secrecy. If your server still offers TLS 1.0 or 1.1, that's a misconfiguration worth fixing.
A crucial property of modern TLS: forward secrecy (also called perfect forward secrecy, PFS). It means that even if an attacker records your encrypted traffic today and later somehow obtains the server's private key, they still cannot decrypt the old traffic.
This works because each TLS session generates a fresh, temporary session key via Diffie-Hellman. The session key is never stored. When the session ends, the key is discarded. The server's long-term private key is used only for authentication — it never touches the actual encryption keys.
"If you captured TLS traffic that you could not decrypt today, but you then in the future managed to obtain a certificate — even an expired, retired certificate — from a server that had been involved in that initial negotiation, you were able to come back and decrypt traffic from the past that you had captured. That's lack of perfect forward secrecy. That is not possible to do under TLS 1.3."
This is not theoretical. Nation-state adversaries are known to record encrypted traffic at scale, betting on future access to keys. Forward secrecy closes that window entirely — the session keys are ephemeral and gone.
| Type | Validation Level | What Was Verified | Cost |
|---|---|---|---|
| DV | Domain Validation | You control the domain (automated DNS/file challenge) | Free (Let's Encrypt) |
| OV | Organization Validation | DV + organization name verified by CA | $50–$300/yr |
| EV | Extended Validation | OV + legal entity, jurisdiction, business registration verified | $100–$500/yr |
| Wildcard | DV or OV | Covers all subdomains: *.example.com |
Varies |
| SAN/Multi-domain | DV or OV | Covers multiple specific hostnames in one cert | Varies |
For most websites — including this one — a free DV certificate from Let's Encrypt is exactly right. Let's Encrypt automated the entire issuance process and has issued over 4 billion certificates since 2015. There's no reason to pay for a certificate on a standard web property.
This is the part that matters for security awareness.
The padlock means:
The padlock does NOT mean:
paypa1.com can have a valid padlock.Over 80% of phishing sites now use HTTPS. The padlock is a check on the transport — it says nothing about the destination. A valid certificate for secure-login-paypal.suspicious-domain.com is easy to get. Always verify the full domain name, not just the padlock.
When a private key is compromised or a cert is issued in error, the CA needs to revoke it before it expires. Two mechanisms handle this:
Since 2018, all publicly trusted certificates must be logged to public Certificate Transparency (CT) logs. This creates an auditable record of every cert ever issued, making it much harder for rogue CAs or attackers to issue unauthorized certificates for your domain without it being detectable. You can monitor CT logs for your domain using tools like crt.sh.
HTTP Strict Transport Security is a response header a server sends:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
It tells your browser: "For the next year, refuse to connect to this domain over plain HTTP — always upgrade to HTTPS." This defeats SSL-stripping attacks where a man-in-the-middle intercepts your initial HTTP request before you're redirected to HTTPS.
HSTS Preloading takes it further: domains that meet strict requirements can be hardcoded into browsers (Chrome, Firefox, Safari, Edge all share the same preload list). Browsers will refuse non-HTTPS connections to preloaded domains before even checking the header — no initial HTTP request at all.
Server Name Indication (SNI) is an extension that sends the hostname you're connecting to in the TLS ClientHello — in plaintext, before encryption is established. This is necessary because many servers host multiple domains on the same IP (virtual hosting), and the server needs to know which certificate to present before the TLS handshake completes.
The consequence: even with HTTPS, anyone on the network path can see which hostname you're connecting to. Your ISP knows you visited thedaddyproject.org, even though they can't see what you read. Encrypted Client Hello (ECH) — an extension to TLS 1.3 — encrypts the SNI field. Deployment is still rolling out as of 2026.
# Inspect a server's certificate chain
openssl s_client -connect thedaddyproject.org:443
# See cert expiry, subject, SANs
echo | openssl s_client -connect example.com:443 2>/dev/null \
| openssl x509 -noout -dates -subject -ext subjectAltName
# Test which TLS versions a server supports
nmap --script ssl-enum-ciphers -p 443 example.com
# Check HSTS header
curl -sI https://example.com | grep -i strict