I provide this information for reference when examining TLS in Wireshark. The TLS 1.2 protocol ladder (also called the TLS handshake ladder) describes the step-by-step sequence of message exchanges between a client and server as they negotiate a secure, encrypted connection.
Think of it as a “ladder” where each side alternates rungs (messages) upward until a shared, authenticated session key is established.
Here’s the process:
Step 1. Client Hello
- Client → Server
- Sends the TLS version it supports (e.g., 1.2)
- Lists supported cipher suites, compression methods, and extensions (like SNI)
- Sends a random value (Client Random)
Step 2. Server Hello
- Server → Client
- Chooses the TLS version and cipher suite
- Sends its own random value (Server Random)
- May send session ID for resumption
Step 3. Server Authentication
- Server → Client
- Certificate: Contains the server’s public key (and possibly intermediates)
- ServerKeyExchange: (Only if required, e.g., for ephemeral Diffie-Hellman)
- CertificateRequest: (Optional, if the server wants to authenticate the client)
- ServerHelloDone: Indicates end of server hello messages
Step 4. Client Authentication and Key Exchange
- Client → Server
- Certificate: (Optional, if client authentication requested)
- ClientKeyExchange: Contains the key material for deriving the shared secret
- For RSA: Encrypted premaster secret using server’s public key
- For DHE/ECDHE: Client’s public key component
- CertificateVerify: (If client certificate used) proves client owns private key
Step 5. Session Key Generation
- Both sides independently derive the master secret:
master_secret = PRF(pre_master_secret, "master secret", ClientRandom + ServerRandom) - From this, they derive symmetric encryption and MAC keys.
Step 6. Handshake Completion
- Client → Server:
ChangeCipherSpec, thenFinished(encrypted and MAC-verified) - Server → Client:
ChangeCipherSpec, thenFinished(encrypted and verified) - Both verify that the handshake messages match the expected hashes, proving integrity.
Step 7. Secure Data Exchange
After the “Finished” messages are validated, both sides switch to encrypted communication using the negotiated cipher suite.
Here is an Example Packet Capture
You will find this example and others in our comprehensive pcap file here.
Here is a summary of the “Ladder”
| Step | Direction | Message | Purpose |
|---|---|---|---|
| 1 | Client → Server | ClientHello | Start negotiation |
| 2 | Server → Client | ServerHello | Confirm parameters |
| 3 | Server → Client | Certificate (+KeyExchange) | Authenticate server |
| 4 | Client → Server | ClientKeyExchange (+Cert) | Send key material |
| 5 | Both | Key Derivation | Compute shared secret |
| 6 | Both | ChangeCipherSpec / Finished | Confirm encryption works |
| 7 | Both | Application Data | Secure session begins |
If you would like to help support the continued development of independent networking, broadband, Wi-Fi, VoIP, and packet analysis content, please consider joining our Patreon community where you will gain access to exclusive technical resources, downloadable labs and PCAPs, bonus course content, troubleshooting guides, and additional member-only material. Comments and technical discussion are always welcomed at our Patreon community or on our Discord server. You can also support our work by simply buying us a coffee — every contribution helps us continue creating practical, real-world network science education for professionals and enthusiasts alike.