TLS & HTTPS
What the padlock actually guarantees — and the three things it does not.
30 minDifficulty 3/5security · networkingAI-writtenWritten by a model on 16 August 2026 and not yet read by a person. Checked automatically: schema, the pedagogical rules the hand-written material is held to, and every diagram parsed for real.
Before this
Why this exists
The padlock icon in a browser's address bar reassures people the connection is "secure" — but secure against what, exactly? TLS guarantees the connection is encrypted (nobody eavesdropping can read it) and that you're talking to the domain you think you're talking to. It says absolutely nothing about whether that site is trustworthy, honest, or safe to enter your password into — a phishing site can have a perfectly valid padlock too.
The mental model
TLS solves exactly three problems for a connection: encryption (nobody in between can read the data), integrity (nobody in between can silently modify the data without detection), and authentication (you can cryptographically verify you're actually talking to the domain named in the certificate, not an impostor). It solves nothing beyond those three — content trustworthiness is an entirely separate concern.
How it works
A certificate authority's signature is what makes a certificate trustworthy
A server presents a certificate claiming 'I am example.com' along with a public key — but anyone could claim that. What makes it credible is a digital signature from a Certificate Authority (CA) the browser already trusts, vouching that they verified this domain's ownership before issuing the certificate. Without that chain of trust back to a known CA, the certificate is just an unverifiable claim.
Asymmetric cryptography bootstraps a shared symmetric key
The TLS handshake uses asymmetric (public/private key) cryptography ONLY to securely agree on a shared secret key — asymmetric operations are computationally expensive, so they're used just once, briefly, to establish trust and exchange a key. All the ACTUAL data transfer afterward uses fast symmetric encryption with that agreed-upon shared key, which is orders of magnitude cheaper to compute for every subsequent byte sent.
HTTPS is HTTP running inside a TLS-encrypted tunnel — nothing about HTTP itself changes
HTTPS isn't a different protocol with different semantics — it's exactly the same HTTP request/response methods, headers, and status codes, just wrapped inside an encrypted TLS connection instead of a plain, readable one. Anything a proxy or network observer could read from plain HTTP (the full URL path, headers, body) is completely opaque over HTTPS, visible to the observer only as encrypted bytes plus which server IP/domain was contacted.
TLS says nothing about what happens after the connection — application-level security is still your job
TLS protects data IN TRANSIT between the client and server — it does nothing about SQL injection, XSS, weak password hashing, or a compromised server storing plaintext credit card numbers. A perfectly configured TLS setup on a server with an SQL injection vulnerability is still completely broken; the two are entirely independent security layers addressing different threats.
The mechanism
The client and server first negotiate which cryptographic methods to use, and the server presents its certificate for the client to verify against known, trusted certificate authorities. Once trust is established, both sides use asymmetric cryptography briefly to agree on a shared symmetric key without ever transmitting that key itself in a way an eavesdropper could capture. From that point, all actual HTTP traffic is encrypted with the fast, shared symmetric key.
sequenceDiagram participant C as Client participant S as Server C->>S: ClientHello (supported ciphers) S->>C: ServerHello + certificate (signed by a trusted CA) Note over C: verify certificate's signature and domain match C->>S: encrypted key exchange (asymmetric crypto) Note over C,S: both now derive the SAME shared symmetric key C->>S: HTTP request, encrypted with shared key S->>C: HTTP response, encrypted with shared key
What people get wrong
- The padlock icon means a website is safe and trustworthy.
- The padlock only confirms the connection is encrypted and you're genuinely talking to the domain named in the certificate — it says nothing about whether that domain's operators are honest, and a phishing site can obtain a perfectly valid certificate for its own (different) domain. This confusion is exactly why phishing sites routinely use HTTPS themselves — the padlock was never a trustworthiness signal, only an identity-and-encryption one, and users trained to 'look for the padlock' can be misled by a technically valid one on a malicious site.
- HTTPS encrypts everything about a request, including which domain you're visiting.
- The domain being contacted (via SNI, Server Name Indication, in the initial handshake, and via DNS lookups before the connection even starts) is typically visible to network observers — HTTPS encrypts the request PATH, headers, and body, but not, in most configurations, which domain was contacted. This matters for anyone assuming HTTPS provides full privacy about their browsing destinations, when in practice an ISP or network observer can usually still see which domains are being visited, just not what's requested from them.
- Using HTTPS means the application itself is secure.
- TLS secures the connection between client and server — it does nothing to prevent SQL injection, XSS, weak authentication, or any application-level vulnerability, all of which remain entirely the application's own responsibility regardless of TLS. Conflating transport security with application security leads to a false sense of safety — a site can be fully HTTPS and still be trivially compromised through an unrelated vulnerability TLS was never designed to address.
When not to use it
- You need to verify a piece of content hasn't been tampered with by a party OTHER than the two endpoints of the connection, like a downloaded file's integrity.
- A separate integrity mechanism (a checksum, a digital signature on the file itself) — TLS protects the connection in transit, not the long-term integrity of content after it's been received and stored.
- You want to hide even WHICH domains a user is visiting from network observers.
- Additional privacy tools (like a VPN, or protocols addressing SNI encryption) — plain HTTPS alone typically still reveals the destination domain even though it hides the request's content.
Terms
- Certificate Authority (CA)
- — A trusted third party that verifies domain ownership and digitally signs certificates, forming the basis of trust in TLS.
- TLS handshake
- — The initial exchange where client and server negotiate cryptographic parameters, verify the certificate, and establish a shared symmetric key.
- Symmetric encryption
- — Encryption using the same key for both encrypting and decrypting, fast enough for bulk data transfer, established via the handshake's asymmetric exchange.
- SNI (Server Name Indication)
- — A field in the TLS handshake revealing which domain the client intends to connect to, typically visible to network observers even over HTTPS.
In an interview
Why does TLS use asymmetric cryptography only briefly during the handshake, rather than for the entire connection?
- asymmetric cryptography is computationally expensive relative to symmetric encryption
- it's used specifically to securely establish a shared symmetric key without transmitting it in a capturable form
- once that shared key is established, the much faster symmetric encryption handles all the actual data transfer for the rest of the connection
Can you recall it?
What three specific guarantees does TLS provide, and what does it explicitly NOT guarantee about a website?