HTTP vs HTTPS

HTTPS is HTTP wrapped in TLS. The protocol semantics (methods, status codes, headers, bodies) are identical. The difference is the channel: HTTPS connections are encrypted, authenticated, and tamper-evident; HTTP connections are not. This matters more than people new to web development usually realise.

The three properties TLS adds

• Confidentiality. Anyone sniffing the network sees encrypted bytes, not the URL, headers, or body. Without TLS, your bearer token, your cookies, and your password reset link are visible to every router, ISP, and coffee-shop wifi between you and the server.
• Integrity. Anyone modifying the bytes in transit (an MITM proxy, a malicious wifi captive portal, a content-injecting ISP) breaks the cryptographic checksum, and the client rejects the connection. Without TLS, intermediaries can rewrite responses.
• Server authenticity. The server presents a certificate signed by a trusted Certificate Authority. The client verifies the signature and the hostname before trusting anything. Without TLS, you cannot tell if you are talking to the real server or someone impersonating it.

What TLS does NOT protect

• The hostname. TLS encrypts the URL path and headers, but the hostname (gorest.co.in) is visible to anyone on the network during the handshake. Modern TLS (1.3+) with Encrypted Client Hello (ECH) hides this too, but support is still rolling out.
• Traffic patterns. An observer can see how often you connect, how big the packets are, and roughly how long the response was. Side channels still leak metadata.
• The endpoints themselves. TLS protects the wire, not the servers at each end. If your server logs all request bodies and the log file leaks, TLS bought you nothing.
• Application-level bugs. XSS, SQL injection, broken authorisation: none of these are about transport security. HTTPS is necessary but nowhere near sufficient.

Why "mixed content" errors exist

When an HTTPS page tries to load an HTTP resource (an image, a stylesheet, an XHR request), the browser blocks or warns. The reason: the HTTPS page promises confidentiality and integrity for everything on it. An HTTP load breaks that promise. Someone could MITM the image to inject a tracking pixel, or rewrite the script to steal cookies.

The fix is always the same: serve everything over HTTPS. There is no good reason in 2025 to serve any production resource over plain HTTP.

Certificates 101

A TLS certificate is a signed statement: "the public keyXXX belongs to the hostnameexample.com, issued by Trusted CA, valid until 2025-12-31". The browser ships with a list of trusted CAs (Mozilla's CA bundle on Linux, the OS keychain on Mac/Windows). When the server presents a cert, the browser walks the signature chain back to a trusted root.

Three modern shifts:

• Let's Encrypt. Free certs, automated renewal, used by half the internet. There is no reason to pay for a basic cert.
• Short lifetimes. Certificates used to last 3 years; now 90 days is standard, and 6 days is rolling out. Shorter lifetimes mean faster recovery if a key is compromised.
• Certificate Transparency. All public certs are now logged in append-only public ledgers. Site owners can detect rogue certs issued for their domain.

TLS versions

• TLS 1.2 (2008). The workhorse. Still acceptable. Avoid all earlier versions (SSL, TLS 1.0, 1.1); they have known weaknesses and are deprecated.
• TLS 1.3 (2018). Faster handshake (1 round-trip instead of 2), simpler cipher menu, fewer footguns. Use it if you can.

Servers usually accept both 1.2 and 1.3 clients. The protocol negotiates down to whatever both sides understand.

SSL vs TLS

SSL is the old name. TLS is the current name. SSL 3.0 was renamed TLS 1.0 in 1999. People still say "SSL certificate" out of habit, but every cert in production is a TLS cert. The terms are interchangeable in casual speech; in technical writing, use TLS.

Why public APIs must be HTTPS-only

Three concrete reasons:

• Bearer tokens. An API key or bearer token sent over HTTP is visible to every router along the path. With HTTPS, only the endpoints see it.
• CORS. Browsers refuse to attach credentials (cookies, Authorization headers) to cross-origin HTTP requests when the page is HTTPS. The API must be HTTPS, or the client cannot use it.
• Trust. Modern browsers display "Not secure" warnings on plain HTTP, refuse new features (service workers, geolocation) without HTTPS, and Chrome will block subresources from loading. The user-facing cost of plain HTTP is now bigger than the cost of a free Let's Encrypt cert.

The Go REST API is HTTPS-only at gorest.co.in. There is no plain-HTTP fallback because there should not be one.

The smallest useful TLS knowledge

If you remember one thing about HTTPS: it makes the connection private and verified. It does not make the server safe, the data correct, or the application secure. Treat HTTPS as table stakes, not a security strategy.