Why Transport Security Is Non-Negotiable
Every byte of data traveling between a browser and a server is a potential target. Without proper transport security, attackers on the same network can read, modify, or inject content into those communications. TLS, HTTPS, and HSTS form a layered defense that addresses this threat — but many developers treat them as interchangeable when they each serve a distinct role.
TLS: The Cryptographic Engine
Transport Layer Security (TLS) is the cryptographic protocol that encrypts data between two parties. It replaced SSL (which is now deprecated and insecure) and operates below the application layer, meaning it works with HTTP, SMTP, FTP, and others.
A TLS handshake accomplishes three things:
- Authentication: The server proves its identity using a certificate signed by a trusted Certificate Authority (CA).
- Key exchange: Both parties negotiate a shared session key without transmitting it directly (typically via ECDHE).
- Encryption: All subsequent data is encrypted using the negotiated symmetric cipher (e.g., AES-GCM).
TLS 1.3, the current standard, eliminated weak cipher suites, reduced handshake round trips, and made forward secrecy mandatory. If your servers still support TLS 1.0 or 1.1, disable them immediately — they are vulnerable to known attacks like POODLE and BEAST.
HTTPS: HTTP Over TLS
HTTPS is simply HTTP running on top of a TLS connection. It is not a separate protocol — it is a combination that ensures the HTTP request and response are encrypted and the server is authenticated. HTTPS operates on port 443 by default.
The browser signals a secure connection via the padlock icon, but the real signal is the certificate chain. A valid certificate must:
- Be issued by a trusted CA (or a CA in the browser's trust store)
- Match the domain name being visited
- Not be expired or revoked
Mixed content — loading HTTP resources on an HTTPS page — undermines the security guarantee. Modern browsers block or warn on active mixed content (scripts, iframes) and are increasingly blocking passive mixed content (images, audio) too.
HSTS: Locking In HTTPS
HTTP Strict Transport Security (HSTS) is a response header that instructs browsers to never connect to your site over plain HTTP again, for a specified duration. Without HSTS, even if you redirect HTTP to HTTPS, a user's very first request could be intercepted before the redirect.
A typical HSTS header looks like this:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload- max-age: Seconds the browser enforces HTTPS-only. Two years (63,072,000s) is the recommended minimum for preload eligibility.
- includeSubDomains: Extends the policy to all subdomains. Ensure all subdomains serve valid HTTPS before enabling this.
- preload: Opts your domain into the HSTS preload list, hardcoded into browsers. This eliminates even the first-visit vulnerability.
How They Work Together
| Layer | Role | Without It |
|---|---|---|
| TLS | Encrypts and authenticates the connection | Data visible to network attackers |
| HTTPS | Delivers HTTP over an encrypted channel | Web traffic is plaintext |
| HSTS | Forces browsers to always use HTTPS | First-visit downgrade attacks possible |
Practical Checklist
- Use TLS 1.2 minimum; prefer TLS 1.3.
- Obtain certificates from a trusted CA (Let's Encrypt is free and widely trusted).
- Redirect all HTTP traffic to HTTPS at the server level.
- Set an HSTS header with a long max-age on your first HTTPS response.
- Submit your domain to the HSTS preload list at hstspreload.org once you're confident.
- Test your configuration regularly with tools like SSL Labs' SSL Test.
Getting these three layers right is the minimum baseline. From here, additional headers like CSP and security-related DNS records build further protection.