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.
Read this lesson as text6 chapters · quiz answers
01What 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.
02ClientHello — the opening offer
Your browser sends one packet that says: 'here's what I support, here's which site I want, and here's half of a math puzzle to start setting up keys.' Sending that puzzle piece in the very first packet is how TLS 1.3 starts encrypting twice as fast as the old TLS 1.2.
03ServerHello + keyshare — channel goes encrypted
The server picks one of each: version, encryption algorithm, and curve. Then it sends back its half of the math puzzle. The two halves combine into a shared secret that nobody listening can guess. From this point on, everything is encrypted.
04Server proves identity: Certificate + CertificateVerify + Finished
Now the server proves who it is. It sends its certificate — a document saying 'this public key belongs to linuxtools.app, signed by a trusted authority'. Anyone can copy a certificate, so the server ALSO signs the conversation so far with its private key. That fresh signature proves: yes, I really am the holder of this certificate, right now.
05Client verifies, then Finished
Your browser checks the certificate: is it from a trusted authority, is the hostname right, is it still in date, and is the fresh signature genuine? If everything passes, your browser sends its own 'I'm done' message back. Handshake complete.
06Application data — and why old traffic stays safe
Now the real traffic flows, encrypted both ways. Here's the magic: the keys came from a fresh math puzzle that both sides throw away when the connection ends. Even if someone steals the server's certificate key tomorrow, they still can't decrypt today's recorded traffic. That property is called perfect forward secrecy.
Quiz — answers
- In TLS 1.3, which message contains the client's ephemeral Diffie-Hellman public key?
- →ClientHelloTLS 1.3 puts the client's keyshare in ClientHello as a preemptive guess for which curve the server will pick. That's why 1.3 reaches application data in 1-RTT (vs 2-RTT in 1.2, which had a separate ClientKeyExchange).
- What exactly does the CertificateVerify message prove, and why isn't the Certificate message alone enough?
- →It proves the server holds the cert's private key RIGHT NOW for THIS handshake — preventing replay of a cert captured from somebody else's connection.Anyone can copy a cert (it's public). CertificateVerify is a fresh signature over the unique handshake transcript using the cert's private key — that's the proof the server actually holds the key. Without it, an attacker who intercepted a valid Certificate from somewhere could MITM you.
- What is perfect forward secrecy (PFS), and how does TLS 1.3 guarantee it?
- →Each session uses fresh ephemeral Diffie-Hellman keys; the long-term cert key is used only to sign. If the cert key leaks later, past recorded sessions still cannot be decrypted.PFS = the secrets that decrypt this session are independent of the long-term identity key. TLS 1.3 makes ephemeral (EC)DHE mandatory, so the cert key signs but never seeds session keys. TLS 1.2 with RSA key exchange did NOT have PFS — that's one of the main reasons 1.2 RSA suites are deprecated.
- Why does a load balancer hosting many sites on one IP need SNI from the client?
- →To pick which certificate to present, because the cert must be sent before the URL or Host header.TLS happens before HTTP, so the Host: header isn't available yet. SNI sends the desired hostname in ClientHello so the server can present the matching cert. ALPN is for the next-protocol question (h2 vs http/1.1). Encrypted ClientHello (ECH) hides SNI from passive observers but is still rolling out.
keep going — these pair well with what you just learned.
SELinux booleans
Runtime on/off switches that toggle whole chunks of policy — getsebool, setsebool -P, finding the right one, and the denial-fixing workflow. RHCSA-ready.
How SSH key auth works
The six-step handshake — key offer, challenge, signature, verification, channel open. Watch an animated client/server diagram light up each arrow.