SSL/TLS Explained — How HTTPS Encrypts the Web and How Certificates Work

TLS provides exactly three properties, no more.

• Confidentiality — nobody who taps the wire can read the traffic (AES-GCM / ChaCha20-Poly1305)
• Integrity — tampering with the traffic is detectable (AEAD authentication tag)
• Authentication — the party you are talking to is who they claim to be (X.509 certificate + PKI)

The third one — authentication — is by far the most important: without it the first two are meaningless. If an attacker is sitting in the middle, "encrypted communication with the attacker" is exactly what you get. Flags like curl -k or --insecure throw away this guarantee, and they have no place in production.

The position TLS sits in is between the Application layer and the Transport layer. HTTP runs on TCP; HTTPS becomes a three-layer stack of HTTP → TLS → TCP, with TLS encrypting and decrypting transparently to the layers above and below. In HTTP/3, TLS 1.3 is built directly into QUIC — a custom transport on top of UDP.

The handshake is the heart of TLS. It performs key exchange and peer authentication, and establishes the session key that protects the rest of the connection. In TLS 1.3 the whole thing completes in 1-RTT (one round trip) — half the cost of TLS 1.2.

Step through it yourself — follow how messages bounce between client and server from ClientHello to Finished and the encrypted channel is established.

The key trick is that ClientHello carries key_share with it: the client commits to an ECDHE public key on speculation, so the very first server response can finish the key exchange. TLS 1.2, by contrast, had a 2-RTT structure where the client waited for ServerHello and only then sent ClientKeyExchange.

A server certificate is an X.509 structure — a bundle of fields like this:

• Subject — CN=hackinglabo.com, with target domains enumerated in the SAN (Subject Alternative Name)
• Issuer — which CA signed it
• Validity — expiry window (public CAs cap at 398 days)
• Public Key — the public key for this domain (RSA / ECDSA / Ed25519)
• Extensions — Key Usage / EKU / AIA / CRL DP / SCT (Certificate Transparency)
• Signature — the CA's signature over all of the above

A real server certificate never stands alone. It is the leaf of a chain — "Root CA → Intermediate CA → Server Cert" — and the leaf is signed by an intermediate which is signed by a root. Trust is established only when the chain can be walked all the way back to a Root CA that is preloaded into the OS / browser trust store.

Let's Encrypt and ACME automation #

Launched in 2015, Let's Encrypt is a free, fully-automated CA that today issues more than half of all HTTPS certificates worldwide. The protocol is ACME (RFC 8555), and tools like certbot / acme.sh automatically prove domain ownership (HTTP-01 / DNS-01 / TLS-ALPN-01) and acquire / renew a 90-day certificate on a schedule.

Revocation and Certificate Transparency #

When a private key leaks, the certificate must be forcibly invalidated — that's revocation. The modern combination is OCSP Stapling (the server fetches an OCSP response and ships it with the handshake) plus CRLite / OneCRL (the browser receives a bloom-filter bundle of revoked certs).

To detect mis-issuance, Chrome has required CAs to log every issued certificate to public Certificate Transparency logs since 2018. The certificate carries SCTs from at least two independent CT logs. Operators can monitor crt.sh to see every certificate ever issued for their domain by any CA — the single best tool for catching mis-issuance early.

In TLS 1.2 a cipher suite was a single string that specified "key exchange + authentication + symmetric cipher + MAC" — four orthogonal pieces in one identifier. TLS 1.3 dramatically simplified this, and the combinations you'll actually see in modern operations are a small finite list.

Key exchange — Forward Secrecy is the watershed #

Forward Secrecy (FS, PFS) is the property that a future leak of the long-term private key does not allow decryption of past traffic. Only ephemeral-key exchanges — DHE / ECDHE — provide this. The classic "RSA key exchange", where the client encrypts a Premaster with the server's RSA public key and ships it, fails this property: if the RSA private key ever leaks, every past session can be decrypted. This is exactly why TLS 1.3 removed RSA key exchange entirely. In practice today the key exchange is almost always X25519 or ECDHE P-256.

AEAD fuses encryption and authentication #

AEAD (Authenticated Encryption with Associated Data) is a construction that performs encryption and integrity check as one operation. It structurally eliminates the kind of ordering problems ("encrypt-then-MAC vs MAC-then-encrypt") that bred padding-oracle attacks. TLS 1.3 allows only AEAD, and in practice the choices are three:

• AES-128-GCM / AES-256-GCM — extremely fast on CPUs with AES-NI, the server-side default
• ChaCha20-Poly1305 — fast on mobile CPUs without AES-NI; led by Google
• AES-CCM — a lightweight variant for IoT

Server certificate signing keys #

There are three families of key type the server certificate can use. From oldest to newest: RSA-2048 / 3072 (maximum compatibility), ECDSA P-256 / P-384 (smaller, faster), and Ed25519 (standardised in TLS 1.3, the newest). For a general-purpose public website, a dual certificate of ECDSA P-256 + RSA-2048 is the safe choice.

Almost every TLS-related fault — bad certificate chain, missing SNI, fallback to an old protocol, expired certificate — can be diagnosed with a single binary: openssl.

For an online equivalent, Qualys SSL Labs is the standard — it grades you A+ / A / B. Worth running once before any production launch.

The history of TLS vulnerabilities is exactly the history of what modern configuration must throw away. Knowing just the famous ones makes today's hardening guidance feel obvious instead of arbitrary.

MITM (man-in-the-middle) and modern defenses #

Mis-issuance by a CA (DigiNotar 2011, Symantec 2017) and "TLS inspection" appliances at the corporate or home-router edge that swap the certificate on the fly — these MITM scenarios are still real today. The standard defense stack combines:

• HSTS — once a site has been reached over HTTPS, refuse plain HTTP; preload via hstspreload.org
• Certificate Transparency — visible audit trail of every issued cert; monitor with crt.sh
• DANE / TLSA — bind certificates to DNS via DNSSEC (operational burden is high)
• CRLite / OneCRL — browser-side revocation distributed in bulk

Boiling all of this down for day-to-day operation, two things matter: choosing the right profile, and building a system that doesn't quietly rot.

Use Mozilla's templates #

You don't need to design the cipher-suite list yourself. The Mozilla SSL Configuration Generator (ssl-config.mozilla.org) ships three copy-paste profiles that have become the de facto industry standard.

Operational loops that catch drift #

Configure once and walk away is the path to incidents. Build automatic renewal and periodic checks so you actually notice when something is wrong. Most TLS production incidents trace back to a manual step someone left in place.

• certbot / acme.sh + cron for automatic certificate renewal — any manual step will eventually be missed and you'll ship an expired certificate
• Enable OCSP Stapling — fixes both the revocation-check latency and the privacy leak in one
• HTTP → HTTPS 301 + HSTS preload registration (hstspreload.org) — structurally close the cleartext door
• Run testssl.sh / Qualys SSL Labs on a schedule — twice a year is a reasonable cadence, plus on any major CVE
• CT monitoring via crt.sh — catch mis-issuance against your domains early
• Keep OpenSSL patched — assume more Heartbleed-class CVEs will appear, and have a patching procedure ready