TLS / HTTPS Handshake

TLS 1.2 vs. TLS 1.3: the handshake, step by step

TLS 1.3 isn't just "TLS 1.2 but faster" by coincidence — it was redesigned specifically to cut the round trips before any application data can flow.

Certificate chain: who do you actually trust?

A browser doesn't trust a website's certificate directly — it trusts a short chain back to a Certificate Authority whose root certificate shipped with your OS or browser.

Anatomy of a cipher suite

A TLS 1.2 cipher suite name packs several independent algorithm choices into one string. Hover each piece:

TLS 1.3 simplifies this to names like TLS_AES_128_GCM_SHA256 — it always uses ephemeral (EC)DHE key exchange and moved authentication into a separate signature step, so the suite name only needs to describe the bulk cipher and hash.

Common gotchas

• Certificate expiry causes real outages. A single expired leaf certificate can take an entire service down instantly and very visibly — automated renewal (e.g. via Let's Encrypt / ACME) exists specifically to eliminate this as a human failure mode.
• "HTTPS" doesn't mean encrypted end-to-end. A CDN or load balancer that terminates TLS decrypts traffic right there — anything between it and your actual origin server needs its own, separate TLS connection to stay encrypted the whole way.
• Forward secrecy only holds with ephemeral key exchange. Older TLS 1.2 configurations using static RSA key exchange (no ECDHE) mean a single future key compromise can retroactively decrypt every session ever recorded — this is exactly why TLS 1.3 made ephemeral exchange mandatory.
• Downgrade attacks target the negotiation itself. The handshake's Finished message includes a check covering everything negotiated so far, specifically so a MITM can't quietly force a weaker cipher suite without both sides detecting the tampering.