The TLS 1.3 handshake, deep.
Open every message that crosses the wire when a browser starts an HTTPS connection. ClientHello, ServerHello, Certificate, CertificateVerify, Finished — what's in each field, why the cert never proves identity by itself, and how perfect forward secrecy keeps yesterday's traffic safe even if today's cert key leaks.
Deep walkthrough of the TLS 1.3 handshake. Animated message sequence diagram covering ClientHello, ServerHello, Certificate, CertificateVerify, Finished. Includes cipher suite breakdown, SNI, ALPN, HKDF key derivation, and perfect forward secrecy.Open every message that crosses the wire when a browser starts an HTTPS connection. Six steps, six message dumps, and the answer to why your recorded traffic stays safe even if the cert key leaks tomorrow.
- ·Comfortable with the URL flow lesson (DNS → TCP → TLS → HTTP)
- ·Rough sense that asymmetric crypto = public key verifies / private key signs
- ·Don't need to know what HKDF or AEAD are yet — we explain them inline
Name every field in ClientHello and ServerHello. Explain why the cert + CertificateVerify together prove identity. Explain why TLS 1.3 has built-in perfect forward secrecy.
pace: 14 minutes
// arrows numbered to match lesson steps · step 1 is setup-only, so only steps 2 through 6 appear as arrows crossing the wire.
What TLS gives you, and what it doesn't
TLS gives you three things: nobody can read your traffic, nobody can tamper with it, and you know you're talking to the real server. What it doesn't hide: who you're connecting to — an observer still sees the IP and roughly the hostname. It also doesn't fix bugs in the app itself.
The certificate binds an identity to a public key, but a copy of the cert is public — anyone who watched a connection has one. What proves the server actually holds the matching private key is the CertificateVerify signature over this handshake's unique transcript. And because the session keys come from a separate ephemeral Diffie-Hellman exchange — not from the cert key — leaking the cert key tomorrow can't retroactively decrypt the session you ran today.
$openssl s_client -connect HOST:443 -servername HOST -tls1_3$openssl s_client -connect HOST:443 -showcerts < /dev/null$openssl x509 -in cert.pem -text -noout$openssl x509 -in cert.pem -noout -dates -subject -ext subjectAltName$openssl x509 -in cert.pem -noout -fingerprint -sha256$openssl s_client -alpn h2 -connect HOST:443$openssl ciphers -v -s -tls1_3$curl -v --tls13-ciphers TLS_AES_128_GCM_SHA256 https://HOST$curl -kv --resolve HOST:443:IP https://HOST$nmap --script ssl-enum-ciphers -p 443 HOST$ssllabs / testssl.sh HOST$ss -tlnp $/etc/ssl/certs$/etc/pki/ca-trust$update-ca-certificates / update-ca-trust$fullchain.pem / privkey.pemIn TLS 1.3, which message contains the client's ephemeral Diffie-Hellman public key?
What exactly does the CertificateVerify message prove, and why isn't the Certificate message alone enough?
What is perfect forward secrecy (PFS), and how does TLS 1.3 guarantee it?
Why does a load balancer hosting many sites on one IP need SNI from the client?
These aren't graded — they're just for active recall, which is what actually makes the lesson stick.
SSL/TLS Certificate Checker
Point it at any HTTPS host and see the cert chain, validity dates, SANs, and which TLS versions the server accepts — the fields you've just learned to read.