About this interactive
Both handshakes pick up after TCP has made its connection. In TLS 1.2 the client sends a client hello; the server answers with a server hello, its certificate, a server key exchange and a server hello done; the client sends a client key exchange, a change cipher spec and a finished; the server sends its own change cipher spec and finished. Only then can data flow, and encryption only begins with the finished messages. That is why you can open a TLS 1.2 certificate in Wireshark.
TLS 1.3 sets out to talk less and encrypt sooner. The client puts a Diffie-Hellman key share into its very first message, and the server returns its own in the server hello. Where the two sides set up a pre-shared key in advance, the hello names it but never sends the key itself, and usually adds a Diffie-Hellman share as well. From the two shares both sides derive the same symmetric keys, so every handshake message after the server hello is encrypted, the certificate included, and data flows after fewer messages. RFC 8446 describes the handshake in three phases: key exchange, server parameters, authentication.
Some things do not change. The client hello lists the cipher suites the client supports and the server hello names the one chosen. The server proves who it is with its site certificate and an intermediate certificate, checked up to a root certificate on the client's machine; client authentication is optional. And in both versions the data is encrypted with symmetric session keys, never with the server's public key.
About TechKnowSurge
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →