HTTPS and TLS Explained Without the Handshake Diagrams
What the padlock actually guarantees, what happens in the handshake, why certificates cost money, and what your browser is warning about.
HTTPS is HTTP running inside an encrypted, authenticated tunnel. That is the entire claim, and both halves matter: encryption without authentication is just obfuscation, and authentication without encryption only tells you who you are talking to while everybody watches. Getting both right is what the padlock means.
What the padlock does and does not mean
It means your connection to this domain is encrypted, and you have proven that the holder of a private key corresponding to a certificate for that domain is the other end. Nobody on the path — your provider, the café router, a government — can read or modify the content.
It does not mean the site is honest, legitimate, or what it claims to be. It means the connection is to whoever holds that domain's certificate. A phishing site can have a perfect certificate. A scam site is often served over valid HTTPS precisely because that is now table stakes. The lock is about the pipe, not about the people at the other end.
The handshake, in plain terms
-
Hello and supported versions
The client offers which TLS versions and cipher suites it will accept, plus a key share for the fastest handshake method available in its version.
-
The server picks and presents its certificate
Together with its key share. The certificate names the domain, is signed by an authority the client already trusts, and has a validity period.
-
The client verifies the chain
Is this certificate signed by something I trust, is it for the name I asked for, is it inside its validity window, and has it been revoked? Any failure stops the connection.
-
Session keys are derived on both sides
In the current protocol version this uses an ephemeral key exchange, so the session keys exist in memory for that connection only and the server's long-term private key is never transmitted. This property is often called forward secrecy.
-
From here the connection is symmetric
Both sides use fast symmetric encryption for everything, and the handshake cost is amortised across every subsequent byte. This is why TLS setup latency mattered so much in the early days of HTTPS and why techniques like session resumption and connection preloading exist.
Certificates
A certificate binds a domain to a public key. The binding is only meaningful because a certificate authority — an organisation browsers trust in advance — has verified that the requester controls the domain, then signed that statement. Trust is transitive and pre-installed, which is why there are a hundred-plus roots shipped in your browser's trust store.
This is why certificates used to be expensive: getting a commercial authority to verify domain control meant a phone call, paperwork, and a slow issuance process. Automation changed that. A free certificate issued by a well-known automated authority takes a few minutes, and for a normal site it is now the correct default. What you are paying for when you buy one is the higher assurance level, the insurance, and sometimes the support.
Renewal is automated in every current setup, and an expired certificate is the most common cause of a full site outage, because nothing else fails when the clock runs out. Alerting on expiry is a small piece of work with a very large payoff.
Versions worth knowing
| Name | What it is | Practical note |
|---|---|---|
| HTTP/1.1 | Text protocol, one request at a time per connection | Still everywhere; inefficient with many assets |
| HTTP/2 | Binary framing, many concurrent streams over one connection | Removes most of the head-of-line blocking you get in 1.1 |
| HTTP/3 | HTTP/2 semantics over QUIC, itself over UDP | Survives packet loss better, and recovers from network changes in a single round trip |
| TLS 1.2 | Widely deployed, fine | Use it as a floor, not a target |
| TLS 1.3 | Fewer round trips, less legacy cryptography | The current target. Everything modern supports it |
What the browser warnings mean
- Certificate invalid or expired. Either renewal failed or the system clock is wrong. Check the second one first on a machine that is behaving oddly.
- Name mismatch. The certificate is for a different domain. This is what a domain-typo attack looks like, and it is a strong signal to stop.
- Self-signed. The device that issued it is not in any trust store. Expected for local development; a serious warning anywhere else.
- Not private / connection not secure. The site is served over plain HTTP, or a resource on the page is. This is the mixed content warning.
- Privacy error in certificate. The certificate is malformed, misissued or revoked. Treat it as a stop signal, not a warning.
On mixed content specifically: browsers block active content — scripts, stylesheets, frames, images in some cases — from an insecure origin on a secure page, and now increasingly block insecure images too. A single hard-coded http:// image URL in a template is a common cause of a page that half-works on a correctly configured HTTPS site.
Common questions
Frequently asked questions
Is HTTP dangerous?
It is not confidential and it is not authentic. On a public network, someone between you and the site can read every page and every form submission, and can alter what you receive. It is fine for a local development server and for content that is genuinely public and never changes. For anything else, use HTTPS and redirect, without exceptions.
Do free certificates reduce trust?
No. They are issued by the same major authorities and are trusted identically by every browser. What differs is the level of identity verification behind them, and how the issuer is paid. For a site where users log in, a domain-validated certificate is what you need; extended validation is worth considering where phishing of your brand specifically is a realistic threat, which is a narrower problem than the marketing implies.
Why is HTTPS slower on a page with many small files?
Historically, because of the handshake cost per connection. That is largely solved: HTTP/2 and HTTP/3 multiplex over one connection, session resumption avoids a full handshake, and browsers preconnect while you are still typing a URL. Remaining slowness is almost always about the number of round trips to your own server, which is why connection preloading and fewer, smaller requests matter more than the protocol version.
Do I need HTTPS for a static site with no user accounts?
Yes, for three reasons beyond confidentiality. The padlock reduces the chance a visitor types a password into something they believe is your site. Search engines treat an insecure site as a downgrade. And mixed content and insecure third-party embeds are increasingly blocked outright, so an HTTP site can visibly break as browsers tighten.
Where to go next
These are the services referenced above. Compare them on your own terms before you sign up for anything.