How HTTPS and TLS Work: A Complete Developer Guide

1. The Cryptographic Foundation

HTTPS relies on two complementary types of cryptography working together:

Asymmetric Encryption (Public/Private Key)

A key pair: anything encrypted with the public key can only be decrypted with the private key, and vice versa. The public key is shared openly; the private key never leaves the server. Asymmetric encryption is mathematically expensive — encrypting a 1MB file with RSA takes orders of magnitude longer than with symmetric encryption.

Used in TLS for: identity verification (certificates) and key exchange (establishing a shared secret).

Symmetric Encryption (Shared Secret)

Both sides use the same key to encrypt and decrypt. Extremely fast — AES-256-GCM can encrypt gigabytes per second on modern hardware.

Used in TLS for: encrypting all actual data after the handshake establishes a shared session key.

The central challenge TLS solves: how do two parties agree on a shared symmetric key over a public network without it being intercepted? This is the TLS handshake.

2. The TLS 1.3 Handshake — Step by Step

TLS 1.3 completes in 1 round-trip (TLS 1.2 required 2). Here's exactly what happens:

3. Certificate Chains — The Trust Model

A TLS certificate is a signed document. The chain of signatures creates the trust:

Your server cert (leaf)
    └── signed by Intermediate CA (e.g. "R3" by Let's Encrypt)
        └── signed by Root CA (e.g. "ISRG Root X1")
            └── Root CA is built into browsers/OS (trust anchor)

When a browser verifies your certificate, it walks this chain:

1. Is the leaf certificate's domain correct for this connection? (CN/SAN match)
2. Is the leaf certificate signed by a trusted intermediate? (signature valid?)
3. Is the intermediate signed by a trusted root? (signature valid?)
4. Is the root in the browser/OS trust store? (pre-installed by OS vendor)
5. Has any certificate in the chain been revoked? (OCSP check)
6. Is any certificate expired?

Why intermediate CAs exist

Root CA private keys are the crown jewels of the internet PKI. Root CAs keep their private keys in hardware security modules (HSMs) in air-gapped facilities. They sign intermediate CA certificates, which are online and do the day-to-day work of signing your certificates. If an intermediate CA is compromised, it can be revoked without affecting the root.

Certificate Types

4. TLS 1.2 vs TLS 1.3

TLS 1.0 and 1.1 were officially deprecated in RFC 8996 (March 2021). Disable them on your server. Most CDNs and load balancers have done this automatically.

5. Cipher Suites — What They Mean

A cipher suite is a named combination of algorithms for each role in the handshake. In TLS 1.2 notation:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│    │     │         │       │    │
│    │     │         │       │    └─ MAC hash algorithm
│    │     │         │       └─ Cipher mode
│    │     │         └─ Symmetric encryption algorithm
│    │     └─ Certificate key type
│    └─ Key exchange algorithm (ECDHE = forward secrecy)
└─ Protocol

TLS 1.3 simplified this significantly — cipher suites only specify the symmetric cipher and hash, since key exchange is always ECDHE with forward secrecy:

TLS_AES_256_GCM_SHA384       ← Best choice
TLS_AES_128_GCM_SHA256       ← Also good
TLS_CHACHA20_POLY1305_SHA256 ← Better for mobile (software-optimized)

For TLS 1.2, only configure ECDHE cipher suites (forward secrecy). Avoid RSA key exchange (TLS_RSA_*), RC4, 3DES, and MD5/SHA1-based MAC algorithms.

6. HSTS — Enforcing HTTPS at the Browser Level

HTTP Strict Transport Security prevents SSL stripping attacks. Without HSTS, an attacker on the network can intercept a user's initial HTTP request (before the HTTPS redirect) and serve a fake HTTP version of your site — the browser never sees the HTTPS redirect.

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

• max-age=31536000 — remember for 1 year. Browser will use HTTPS directly, skipping the HTTP redirect entirely.
• includeSubDomains — applies to all subdomains. Only add this if every subdomain serves HTTPS.
• preload — submit to hstspreload.org to be baked into Chrome/Firefox/Safari source code. Strongest protection, but irreversible until removed from the preload list (which takes months).

7. Common HTTPS Attacks and Their Mitigations

Man-in-the-Middle (MitM)

An attacker positions themselves between client and server, relaying traffic while decrypting it. TLS certificate validation prevents this — the attacker would need a certificate for your domain signed by a trusted CA, which requires either compromising a CA or social engineering the domain owner. HSTS and CAA records further reduce this risk.

Downgrade Attack (POODLE, DROWN, FREAK)

Tricks the server and client into negotiating a weaker protocol or cipher suite that is exploitable. Mitigated by: disabling TLS 1.0/1.1, disabling export-grade cipher suites, disabling SSLv3. TLS 1.3 eliminates the negotiation-based attack surface entirely.

Certificate Spoofing

An attacker obtains a certificate for your domain from a rogue or compromised CA. Mitigated by: CAA records (restrict which CAs can issue), Certificate Transparency (CT) logs make all issued certs publicly auditable — you can monitor for unauthorized issuance via services like crt.sh or Facebook's Certificate Transparency monitoring.

OCSP Stapling — Certificate Revocation

Certificate revocation (via OCSP or CRL) lets CAs invalidate compromised certificates before they expire. OCSP stapling has the server pre-fetch and cache the OCSP response, attaching it to the TLS handshake — eliminating the extra OCSP lookup round-trip and protecting user privacy (otherwise browsers phone home to the CA for every HTTPS connection).

8. What HTTPS Does NOT Protect You From

A common misconception is that HTTPS = secure. It provides transport security, not application security:

• HTTPS does not prevent XSS — your attacker is already on your page
• HTTPS does not prevent SQL injection — encrypting a malicious payload doesn't neutralize it
• HTTPS does not hide the hostname — visible in SNI and DNS
• HTTPS does not prevent phishing — phishing sites get TLS certificates too
• HTTPS does not prevent data leaks — if your server sends sensitive data, HTTPS just makes the transmission private, not the data exposure on the server side

HTTPS guarantees: the channel is encrypted, the server is who it claims to be (via the cert chain), and the data was not tampered with in transit. That is all — necessary but not sufficient for a secure application.

Frequently Asked Questions

What is the difference between SSL and TLS?

SSL is the deprecated predecessor (SSL 2.0/3.0, both broken). TLS is the current protocol (TLS 1.2 and 1.3). The term "SSL certificate" is colloquial — the actual protocol is TLS. Disable SSL 3.0 and TLS 1.0/1.1 on all servers.

Does HTTPS encrypt the URL path?

Yes. The hostname is visible (needed to establish the connection via SNI + DNS), but the path, query string, body, and all headers are encrypted.

What is HSTS?

A header that tells browsers to always use HTTPS for your domain for a set period, preventing SSL stripping attacks. Enable with at least max-age=31536000 after confirming your entire site serves HTTPS correctly.

What is the difference between TLS 1.2 and TLS 1.3?

TLS 1.3 is faster (1 RTT handshake vs 2), mandates forward secrecy, removes all legacy/insecure algorithms, and has only 5 cipher suites. Enable TLS 1.3 and keep TLS 1.2 as fallback. Disable 1.0 and 1.1.

What happens when a certificate expires?

Browsers show a hard error blocking users. APIs throw certificate errors and refuse connections. Monitor expiry and renew at least 30 days before it expires. Let's Encrypt handles this automatically.

What is certificate pinning?

Hard-coding a specific cert or public key in a client (usually mobile apps). Prevents MitM with fraudulent certs but causes downtime if you rotate certs without updating the pin. HPKP was deprecated in 2018. Avoid for general web use.