Securing Data in Transit

When data travels across the internet, it passes through dozens of routers, switches, and ISPs. Without encryption, any actor on that path (a coffee shop hacker, an ISP, a government) can read, intercept, or modify the data.

TLS (Transport Layer Security) and its deprecated predecessor SSL (Secure Sockets Layer) solve this by providing three guarantees: 1. Encryption: Hides the data from eavesdroppers. 2. Authentication: Proves the server you are talking to is the real server (not a phishing clone). 3. Integrity: Ensures the data was not tampered with in transit.

When you see HTTPS in your browser, you are using HTTP over a TLS encrypted tunnel.

The TLS Handshake (How it works)

Before any real data (like an HTTP GET request) is sent, the client and server must establish a secure connection via the TLS Handshake.

  1. Client Hello: The browser says "Hello, I want to connect securely. Here are the cryptographic cipher suites I support, and a random number."
  2. Server Hello & Certificate: The server picks the strongest cipher both support. It replies with its own random number and its Digital Certificate.
  3. Authentication: The browser inspects the certificate. It checks the cryptographic signature to ensure it was issued by a trusted Certificate Authority (CA) (like Let's Encrypt or DigiCert). This proves the server actually owns the domain name.
  4. Key Exchange (Diffie-Hellman): The client and server use complex asymmetric math to independently generate the exact same Symmetric Session Key without actually transmitting the key across the wire.
  5. Secure Channel: Now that both sides have the same symmetric key, the handshake is over. All subsequent HTTP traffic is encrypted symmetrically at massive speed.

Forward Secrecy

Modern TLS 1.3 mandates Perfect Forward Secrecy (PFS). In the past, if a hacker recorded all encrypted traffic for years and finally managed to steal the server's private RSA key, they could go back and decrypt all past conversations. With PFS, a brand new, ephemeral key pair is generated for every single session. Even if the server's master private key is stolen, past traffic remains permanently encrypted.

Why SSL is Dead

You will often hear people say "I bought an SSL Certificate." This is a colloquialism. SSL v2 and v3 were deprecated over a decade ago due to severe cryptographic flaws (like the POODLE attack). Today, the entire internet runs on TLS 1.2 or TLS 1.3.

Certificates: The Chain of Trust

The server's "Digital Certificate" is more than a file — it is a chain that answers "who vouches for this server?" In practice, the server presents a single leaf certificate signed by an intermediate certificate, which is itself signed by a root certificate owned by a Certificate Authority (CA) like Let's Encrypt, DigiCert, or Amazon. The browser ingests a small, hardcoded set of trusted roots, and it can verify the leaf only by walking every link in that chain. This is why a misconfigured site that omits the intermediate breaks the chain even though its leaf is perfectly valid, and why "certificate expired" or "certificate invalid" errors are such common misconfigurations — the chain, the hostname (CN/SAN must match the URL), and the validity dates must all be right.

Trust, but Verify: Revocation

A CA's signature is a pledge of identity, not a guarantee of lifetime safety. When a private key is compromised or a certificate is issued by mistake, the certificate must be revoked before its natural expiry. Two mechanisms exist: CRL (Certificate Revocation Lists), big lists of revoked serials that browsers sometimes check, and OCSP (Online Certificate Status Protocol), a real-time "is this cert still good?" lookup performed during the handshake. Shorter-lived certificates (90 days via Let's Encrypt, automated by certbot) shrink the revocation problem from "long-lived leak" to "quickly rotated", which is why auto-renewal is now the industry standard.

Certificate Pinning and Its Costs

Pinning hardcodes the expected certificate or public key for a host inside the client, so pre-TLS interception proxies and rogue CAs cannot impersonate the host even if they hold a valid certificate. Pinning is powerful defense against advanced MITM (it is what prevents your "https://api.bank.com" from being served by a company proxy), but it is a sharp tool: when you rotate the underlying key or CSP, every pinned old client breaks instantly and cannot serve unless you update the app. Modern guidance is to pin spare trust anchors and rotate carefully, or rely on the strictest TLS plus Certificate Transparency, and let pinning be the exception for high-value APIs rather than the default. In the security review, ask "who can issue a certificate for this host, and can the client tell if that issuance was legitimate?" — that question is what the whole PKI is answering.