<b>At what exact byte does a TLS 1.3 handshake start encrypting — and why does it matter?</b>

<b>At what exact byte does a TLS 1.3 handshake start encrypting — and why does it matter?</b>

A defining change in TLS 1.3 versus 1.2 is that most of the handshake itself is encrypted. In 1.2, the server's certificate traveled in cleartext, visible to any observer. In 1.3 it does not. The precise transition point is worth pinning down, because it determines exactly what a passive observer can still see.

The sequence (RFC 8446 §2, §7): ClientHello and ServerHello are unencrypted — they must be, since they carry the key_share values used to derive keys. The moment both Hellos are exchanged, each side runs HKDF (RFC 5869) to derive the handshake traffic secrets via the key schedule. From the ServerHello onward — EncryptedExtensions, Certificate, CertificateVerify, Finished — everything is AEAD-encrypted under those handshake keys. Then a second derivation produces the application traffic secrets for the actual data.

So the observable plaintext shrinks to: the two Hellos and their extensions. The certificate, the server's identity proof, and the negotiated extensions are now hidden. This is why SNI (in the ClientHello) and the chosen group (in the key_share) became the residual leaks that ECH and later work target — they are the last cleartext standing.

Evidence vs. speculation: the encrypted-handshake design and the two-stage key schedule are normative (RFC 8446 §7.1). What an observer infers from the remaining plaintext — fingerprinting via JA3-style ClientHello hashing — is empirical traffic analysis, not a protocol leak.

<b>Further reading:</b> RFC 8446 §2, §7.1; RFC 5869 (HKDF).

<b>Bottom line:</b> Encryption begins immediately after ServerHello, hiding the certificate and identity from observers; the only cleartext left is the two Hellos, which is precisely why SNI and ClientHello fingerprinting are the frontier of TLS privacy work.