HTTPS

HTTPS stands for HTTP Secure. It is the exact same HTTP protocol your browser already uses to fetch pages and call APIs, except every byte travels inside an encrypted TLS tunnel instead of plain text. The S is the only difference, and it changes everything about who can see and modify the traffic.

Plain HTTP sends everything in the clear. Anyone on the path, a coffee-shop Wi-Fi operator, an ISP, a compromised router, can read your passwords, cookies, and form data, and can even inject content into the page. HTTPS closes that hole by giving you three things at once: confidentiality so eavesdroppers see only ciphertext, integrity so tampering is detected and rejected, and authentication so you know the server is who it claims to be.

HTTPS normally runs on TCP port 443, while plain HTTP uses port 80. The protocol underneath the encryption is unchanged, which is why moving a site to HTTPS rarely requires rewriting application code.

When you connect, the browser and server run a TLS handshake before any HTTP data is sent. The browser says hello and lists the TLS versions and cipher suites it supports. The server picks one and sends back its certificate, a file signed by a Certificate Authority such as Let's Encrypt or DigiCert that binds the domain name to a public key.

The browser checks that certificate against its built-in list of trusted CAs, confirms it has not expired, and confirms the name matches the site you asked for. If anything fails, you get the red warning page. If it passes, the two sides use public-key cryptography to agree on a shared symmetric session key. Modern TLS 1.3 uses an ephemeral Diffie-Hellman exchange, which gives forward secrecy: even if the server's long-term key leaks later, past recorded sessions stay unreadable.

Once the key is agreed, the rest of the conversation is encrypted with fast symmetric ciphers like AES-GCM or ChaCha20. TLS 1.3 trimmed the handshake to a single round trip, and session resumption can make repeat visits effectively zero round trips, so the latency cost is small.

The answer today is always. Every production site should serve HTTPS only and redirect HTTP to it. Chrome and Firefox label plain HTTP pages as Not Secure, browser features like service workers, HTTP/2, geolocation, and the camera API refuse to run without it, and Google uses HTTPS as a ranking signal. There is no real case for serving public traffic over HTTP anymore.

The cost is small but real. There is the one-time handshake overhead per connection, certificate management, and the discipline of renewing certificates before they expire. Let's Encrypt made certificates free and automatable, and tools like Certbot or the cert handling built into nginx, Caddy, and cloud load balancers renew them on a schedule, so a forgotten renewal causing an outage is the main risk to watch.

One limit worth knowing: HTTPS encrypts the request path, headers, and body, but the server's IP address and the destination hostname in the older SNI field are still visible to network observers. Encrypted Client Hello is the newer fix that hides the hostname too, but it is not yet universal.

Type https://www.cloudflare.com into a browser and watch what happens. The browser opens a TCP connection to port 443, runs the TLS 1.3 handshake, validates Cloudflare's certificate against a trusted CA, and derives a session key, all in roughly one round trip.

From that point the GET request for the HTML, the response, your cookies, and every image and script are encrypted with AES. A network sniffer on the same Wi-Fi sees only that you connected to a Cloudflare IP on port 443 and some encrypted blobs. It cannot read the page, steal your session cookie, or inject a fake login form.

This is why banks, every login page, and payment flows depend on HTTPS. Without it, a single attacker on the network could capture credentials in plain text or quietly rewrite the page you see.