HTTPS Explained: What Happens When You Visit a Site

HTTPS is HTTP — the request/response protocol browsers have always spoken — run over TLS (Transport Layer Security), which wraps the whole conversation in an encrypted, authenticated tunnel. That wrapper buys you three guarantees: confidentiality (nobody between you and the server can read the traffic), integrity (nobody can tamper with it undetected), and authentication (the server really is the one named in your address bar).

Plain HTTP provides none of the three. Anyone on the same coffee-shop Wi-Fi, any compromised router, any network operator along the path can read your requests and rewrite the responses — inject ads, swap a download for malware, or lift a session cookie. That’s why browsers label plain-HTTP pages “Not secure,” and why the modern web treats HTTPS as the floor rather than a premium feature.

HTTP vs HTTPS at a glance

Behavior	HTTP	HTTPS
Traffic on the wire	Readable by any middlebox	Encrypted
Tampering in transit	Silent and undetectable	Detected; the connection fails
Server identity	Taken on faith	Proven by a certificate
Browser treatment	”Not secure” warning	Padlock, no warning
HTTP/2 and HTTP/3	Unavailable in browsers	Supported
Service workers, geolocation, other powerful APIs	Blocked	Available

The last two rows surprise people: browsers only speak the faster multiplexed protocols over encrypted connections, and HTTP/3 has no unencrypted mode at all. HTTPS is a performance feature as much as a security one.

The handshake: agree on a secret, then go fast

TLS combines two kinds of cryptography because each is good at a different job. Asymmetric (public/private key) cryptography lets two parties who have never met establish a shared secret across a hostile network — but it’s computationally expensive. Symmetric encryption, where both sides use the same key, is extremely fast — modern CPUs accelerate it in hardware — but it requires that shared key to exist first. So TLS uses asymmetric crypto briefly, to establish trust and a secret, then switches to symmetric crypto for the actual data. That hybrid model is the whole trick.

In plain English, the handshake runs:

1. Hello. Your browser announces which TLS versions and cipher suites it supports, and includes its key-exchange material.
2. Certificate. The server replies with its certificate — which contains its public key — signed by a certificate authority.
3. Verification. The browser validates the signature chain against its trusted roots, checks that the certificate covers this exact domain, and checks that it hasn’t expired.
4. Key exchange. Both sides combine their key-exchange material to derive the same shared secret. The secret itself never crosses the wire, so an eavesdropper who records everything still can’t compute it.
5. Encrypted session. Everything that follows is encrypted with fast symmetric keys derived from that secret, and every record carries an authentication tag — which is what makes tampering detectable rather than merely difficult.

Modern TLS completes all of this in a single round trip, so the overhead is measured in milliseconds. The key-exchange step is also where post-quantum cryptography is arriving first, because traffic recorded today could be decrypted later if the key exchange ever falls to a quantum computer.

What a certificate actually proves

A TLS certificate binds a domain name to a public key — nothing more. A certificate authority (CA) issues one after verifying that the requester controls the domain, typically by checking for a specific DNS record or a file served from the site. Your operating system and browser ship with a store of trusted root CAs; roots sign intermediate CAs, and intermediates sign the “leaf” certificates that sites present. When your browser validates that chain, it’s concluding exactly this: a CA my vendor trusts confirmed that whoever holds this private key controls this domain.

Let’s Encrypt turned issuance into a free, automated process, which is the single biggest reason HTTPS went from minority practice to near-universal default — the cost and paperwork excuses are gone.

One wrinkle worth knowing: when a site sits behind a CDN, your TLS session usually terminates at the CDN’s edge, which then opens its own encrypted connection back to the origin server. The padlock covers your leg of the trip, not the whole journey.

What HTTPS doesn’t hide — or promise

HTTPS encrypts the contents of traffic, not its existence. A network observer can still learn:

• Which domains you visit. DNS lookups are plaintext by default, and the TLS handshake itself announces the hostname via SNI (Server Name Indication) so shared servers know which certificate to present. Encrypted DNS and newer handshake extensions narrow this leak, but adoption is uneven.
• Traffic patterns. Timing, frequency, and the sizes of encrypted responses stay visible, and metadata analysis on those patterns can reveal plenty.

Equally important is what the padlock does not promise. It means the connection to this domain is encrypted and the certificate is valid — not that the domain is honest. A phishing site can get a perfectly legitimate certificate for a look-alike domain in minutes. HTTPS authenticates the server you asked for; it can’t stop you from asking for the wrong one. That failure mode is what passkeys attack at a different layer, by binding credentials to the genuine origin.

HSTS: why a redirect isn’t enough

Most sites redirect http:// requests to https://. Helpful — but the first request still leaves your machine unencrypted, and an attacker sitting in the middle can intercept it and quietly keep you on plain HTTP while proxying to the real site. This downgrade trick is known as SSL stripping.

HSTS (HTTP Strict Transport Security) closes that gap with a single response header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

For the max-age period, the browser upgrades every request for the domain to HTTPS before it leaves the machine — there’s no insecure first hop left to strip. The preload flag goes further: domains on the preload list ship baked into browsers, so even a first-ever visit is protected.

Mixed content: one weak link spoils the page

An HTTPS page that loads sub-resources over plain HTTP undermines the whole exercise. An injected HTTP script runs with full access to the “secure” page, and a single unencrypted request can leak a session cookie or a bearer token like a JWT. Browsers therefore block active mixed content — scripts, stylesheets, iframes — outright, and upgrade or block passive content like images. The fix is unglamorous: serve every asset over HTTPS, and add the upgrade-insecure-requests Content Security Policy directive to catch stragglers.

The takeaway

HTTPS is HTTP inside TLS: asymmetric cryptography authenticates the server and bootstraps a shared secret, then fast symmetric encryption carries the actual traffic. Certificates prove domain control through a chain of trust that ends at CAs your browser already ships with, and Let’s Encrypt made that proof free. Keep the limits in view — domain names and traffic patterns stay visible, and a padlock never vouches for a site’s intentions. Deployed properly, with HSTS set and mixed content eliminated, the transport layer becomes the one part of your security story you almost never have to think about.