Why HTTPS Is More Than a Lock Icon

Most developers know they should use HTTPS. Hosting providers enable it automatically, browsers warn users about HTTP sites, and search engines factor it into rankings. But treating HTTPS as a feature to tick off misses the point. Understanding how it actually works helps you configure it correctly, debug connection issues, and make informed decisions about your security posture.

What TLS Actually Does

HTTPS is HTTP layered on top of TLS (Transport Layer Security) — the cryptographic protocol that secures the connection. TLS provides three core guarantees:

  1. Encryption: Data transmitted between client and server is encrypted, preventing eavesdropping on the network.
  2. Authentication: The server proves its identity using a digital certificate, preventing impersonation attacks.
  3. Integrity: Each message includes a cryptographic signature (MAC) so tampering in transit can be detected.

Without all three, your "secure" connection has gaps. A self-signed certificate, for example, provides encryption but fails on authentication — browsers warn users accordingly.

The TLS Handshake, Simplified

When a browser connects to an HTTPS server, a handshake occurs before any application data is sent. Here's the simplified flow:

  1. The client sends supported TLS versions and cipher suites.
  2. The server responds with its chosen cipher suite and its certificate (containing its public key).
  3. The client verifies the certificate against a trusted Certificate Authority (CA).
  4. Both parties derive a shared session key using asymmetric cryptography (no key is ever transmitted).
  5. All subsequent communication is encrypted with that symmetric session key.

TLS 1.3 (the current version) streamlines this process further, reducing handshake round trips and removing legacy cipher suites that were vulnerable to attack.

TLS Versions: Why You Should Enforce TLS 1.2+

Older TLS versions (1.0 and 1.1) have known vulnerabilities and are deprecated. If your server still accepts them, you're exposing users to downgrade attacks. Most modern hosting platforms disable these by default, but it's worth verifying in your server configuration.

  • TLS 1.0 / 1.1: Deprecated. Disable immediately.
  • TLS 1.2: Widely supported, acceptable with strong cipher suites.
  • TLS 1.3: Current standard. Faster, simpler, more secure. Prefer when possible.

Certificates: What Can Go Wrong

Certificate-related mistakes are a common source of security failures and user-facing errors:

  • Expired certificates: TLS certificates have validity periods. Automate renewal with tools like Let's Encrypt + Certbot to avoid outages.
  • Incomplete certificate chains: If your server doesn't send the full chain (leaf cert + intermediate CA), some clients will fail to verify it.
  • Wrong domain coverage: Ensure your cert covers all subdomains you use. Wildcard certs (*.yourdomain.com) can simplify this.
  • Mixed content: Loading HTTP resources on an HTTPS page breaks the security guarantee and triggers browser warnings.

HSTS: Enforcing HTTPS at the Browser Level

HTTP Strict Transport Security (HSTS) is a response header that tells browsers to only connect to your domain over HTTPS — even if the user types http://. This prevents SSL stripping attacks. Set it with a long max-age and include includeSubDomains once you're confident all subdomains are HTTPS-ready:

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

Key Takeaways

  • Enforce TLS 1.2 minimum; enable TLS 1.3 where possible
  • Automate certificate renewal to prevent expiry
  • Send complete certificate chains
  • Eliminate all mixed content on HTTPS pages
  • Implement HSTS once your HTTPS setup is solid

Security isn't a feature — it's a practice. Getting the fundamentals of TLS right is one of the highest-leverage things a developer can do for their users.