The TLS handshake: how to read, measure, and monitor it in Wireshark

An HTTPS connection starts with a TLS handshake the user doesn’t see. Before any encrypted data moves, the two sides agree on a protocol version and pick a cipher suite. They also authenticate identities and exchange the keys that protect the session.

That negotiation takes measurable time, and it can fail. A failure often surfaces as a vague “slow site” complaint that’s hard to pin down.

Reading a real handshake is the fastest way to see where that time goes. Capture the traffic on the wire, and you can separate the DNS, TCP, and TLS timings for one session. That shows the slow phase or the failed message.

This article explains the TLS protocol and walks a TLS 1.2 handshake in Wireshark, message by message. Then it shows how to measure and diagnose handshake timing across your users.

What is a TLS handshake and why does it matter?

A TLS handshake is the short negotiation a client and server run before encrypted data flows. It settles on a TLS version, a cipher suite, each side’s identity, and the session keys. It runs once per new connection, and only after it finishes can the application send real data.

It matters because the handshake runs on the critical path of each HTTPS request. Its latency pushes out connection setup and page load. TLS 1.2 needs two round trips. On a link with 50 ms round-trip time, the handshake alone adds roughly 100 ms before any data moves. TLS 1.3 needs one round trip, which roughly halves that.

The handshake can also fail outright. An expired certificate or a version mismatch ends it with a TLS alert, and the user sees a connection error rather than slow load. TLS 1.3 can send early application data with 0-RTT on a resumed session. That resumed case is the one time data moves in the client’s first flight.

What is TLS?

Transport Layer Security (TLS) provides privacy and data integrity between two communicating applications. It encrypts data so a third party can’t read it in transit, authenticates the peers to verify their identity, and protects messages from tampering. The current version is TLS 1.3, defined in RFC 9846, which obsoletes the earlier RFC 8446.

The capture in this article uses TLS 1.2, originally specified in RFC 5246. That RFC is now obsolete but remains a useful historical reference for the handshake shown here. RFC 9846 specifies TLS 1.3 and adds requirements for TLS 1.2 implementations. Its handshake is also more verbose than TLS 1.3, which makes it a good teaching example. Where the flow differs in TLS 1.3, we call it out.

A note on names: people sometimes use “SSL” and “TLS” interchangeably. SSL itself is obsolete and insecure, as vulnerabilities such as POODLE demonstrated. Modern connections use TLS.

How is TLS structured?

TLS runs between the application and the transport layer, and it splits into two sub-layers. The Record Protocol is the lower layer, with handshake and control sub-protocols above. It traditionally runs over TCP, a reliable transport protocol. TLS 1.3 also runs inside QUIC, which uses UDP and carries HTTP/3.

The TLS Record Protocol is the lower layer, and it handles:

• Fragmenting each message into manageable blocks.
• Encrypting and decrypting the data.
• Applying the Message Authentication Code (MAC), a hash that protects integrity.
• Passing data between the application and transport layers in both directions.

Record-layer compression is a legacy feature. Modern TLS disables it because of attacks such as CRIME, and TLS 1.3 removed it entirely. You’ll see it referenced in the TLS 1.2 messages below, but you shouldn’t enable it.

The higher layer consists of four sub-protocols:

• Alert: Defines alert levels and descriptions, and notifies the peer of an error condition.
• Change Cipher Spec: Signals a switch to the newly negotiated keys. Both peers send it in TLS 1.2.
• Application Data: Fragments, encrypts, and transmits application messages securely.
• Handshake: Negotiates the cipher suite, authenticates the peers with certificates, and exchanges keys.

What’s the difference between TLS 1.2 and TLS 1.3?

TLS 1.3 reworked the handshake for speed and security. It needs one round trip instead of two, encrypts most messages after the ServerHello, and drops legacy algorithms. Those changes alter both the message sequence and what’s visible on the wire. So a TLS 1.2 capture and a TLS 1.3 capture look different in Wireshark. The table below compares the parts that matter when you read one.

Inline CTA:

Copy: For a fuller side-by-side, see LogicMonitor’s TLS 1.2 vs 1.3 deep dive.

Link text: TLS 1.2 vs 1.3 deep dive

Link: https://www.logicmonitor.com/deep-dive/http3-vs-http2/tls1-2-vs-1-3

How do you read a TLS 1.2 handshake in Wireshark?

You read a TLS 1.2 handshake in Wireshark by following the messages in order. Start at the client’s opening hello, end at both sides’ Finished messages, and inspect the fields in each. The session captured below was recorded with Wireshark, a common network protocol analyzer.

TLS 1.3 changes the sequence: it uses fewer round trips, encrypts most of these messages after the ServerHello, and drops several steps shown here. Those TLS 1.2-specific steps are flagged as we go.

Client Hello

The first message is the Client Hello, sent by the client to start a session with the server. It advertises what the client supports so the server can pick from it.

The message contains:

• Version: The highest TLS version the client supports and wants to use.
• Client Random: A 32-byte pseudorandom number used to calculate the master secret.
• Session Identifier: A unique number the client uses to identify a session.
• Cipher Suite: An ordered list of the suites the client supports. This capture offers 28.

Each suite combines a key exchange, a bulk cipher, a MAC, and a pseudorandom function. The client random later feeds the encryption key derivation.

One of the 28 cipher suites offered above is shown here. It’s a legacy TLS 1.2 suite, included because it appears in the capture. Its algorithms are outdated and shouldn’t be used today:

• TLS: The protocol family.
• RSA: The key exchange and peer authentication method.
• 3DES_EDE_CBC: The bulk encryption algorithm.
• SHA-1: The MAC, a cryptographic hash.

In TLS 1.2, the suite name encodes the key exchange and authentication method, RSA here. TLS 1.3 negotiates those separately, so a TLS 1.3 suite name lists only the bulk cipher and hash.

The Client Hello can also carry a Compression Method list. Compression is a legacy feature that modern deployments leave off.

Server response: Hello, Certificate, and key material

The server answers a valid Client Hello with a burst of messages. They select the session parameters, prove the server’s identity, and supply any extra key material. In this TLS 1.2 capture, that burst runs from the Server Hello through Server Hello Done.

Server Hello

The Server Hello reports the choices the server made from what the client offered. It fixes the version, the cipher suite, and the session handling for the rest of the exchange.

The Server Hello contains:

• Server Version: The version the server selects, based on what each side supports and on server policy.
• Server Random: A 32-byte pseudorandom number used to generate the master secret.
• Session Identifier: A session number. The server returns a matching ID to resume a cached session.
• Cipher Suite: The suite the server picks from the client’s list.
• Compression Method: A legacy field that modern servers leave disabled.

For the session identifier, the server sends a new ID when it won’t resume, or an empty ID when resumption isn’t possible. With no common cipher suite, it raises a handshake failure alert.

Server Certificate

The server sends a list of X.509 certificates to authenticate itself, and the certificate carries its public key. Validation anchors in a trusted third party called a Certificate Authority. Trust comes from the well-known CAs shipped with the operating system and browser, or from certificates the user imported.

In the legacy RSA key exchange used by some TLS 1.2 suites, the client encrypts a pre-master secret with this public key. The typical TLS 1.3 flow uses ephemeral Diffie-Hellman instead. There, the certificate’s public key authenticates the server but doesn’t encrypt key material.

Certificate Status

This message carries a signed certificate status response fetched from a designated OCSP (Online Certificate Status Protocol) server. The response is dated and signed, and it reports whether the certificate is revoked. When the server delivers it inline, the approach is called OCSP stapling.

The stapled message supplies the signed status for the client to evaluate. The client, not the message, decides whether to trust the certificate. Stapling saves bandwidth on constrained networks and keeps OCSP servers from being overwhelmed by client requests. To request it, the client includes a “status_request” extension in its Client Hello.

Server Key Exchange

This TLS 1.2 message is optional. It appears when the certificate’s public key isn’t suitable for key exchange, or when the suite requires a temporary key. The client uses the server’s key-exchange parameters together with its own key material to establish the shared secret. With Diffie-Hellman suites, the Client Key Exchange carries the client’s Diffie-Hellman public value rather than an encrypted pre-master secret.

Client Certificate Request

This optional message is sent when the server wants to authenticate the client. An example is a site that must confirm identity before granting access to private information. It names the certificate type required and the list of acceptable Certificate Authorities.

Server Hello Done

This message signals that the server is finished and is awaiting the client’s response. It’s specific to the TLS 1.2 flow; TLS 1.3 doesn’t use a separate Server Hello Done.

Client response: key exchange and Finished

The client now supplies its key material and switches to encrypted communication. This flight runs from the Client Key Exchange through the client’s Finished message.

Client Key Exchange

This message carries the client’s ephemeral elliptic-curve Diffie-Hellman public value. In this capture, the negotiated suite is ECDHE_RSA, so the client and server use their ECDHE key material to derive a shared secret. The server’s RSA certificate key authenticates the exchange; it does not encrypt a pre-master secret.

It contains:

• The client’s EC Diffie-Hellman public value.

Each side combines its own ephemeral private key with the peer’s public value to derive the same shared secret. That shared secret, together with the client and server randoms, is used to derive the TLS 1.2 master secret and session keys. TLS 1.3 also uses ephemeral Diffie-Hellman-style key establishment, but integrates it into a different handshake flow.

Change Cipher Spec

This message signals the server that the client’s next messages will use the keys and algorithm just negotiated. The paired Change Cipher Spec, from client and server, is part of the TLS 1.2 flow. TLS 1.3 removed it from the handshake logic and keeps it only for backward compatibility.

Finished (Encrypted Handshake)

The Finished message is a hash of all previous messages plus a “client finished” label. It signals that TLS negotiation is complete for the client. Wireshark labels it Encrypted Handshake, because unlike the earlier messages it’s encrypted with the newly negotiated keys and algorithm.

Server confirmation: Change Cipher Spec and Finished

The server mirrors the client’s final flight to confirm the switch to encryption and authenticate itself. After these two messages, the secure channel is fully established.

Change Cipher Spec

The server signals the client that its following messages will use the negotiated algorithm and keys. The record layer now switches to symmetric key encryption.

Finished

This message is like the client’s Finished but carries a “server finished” label. Once the client decrypts and validates it, the server is authenticated.

Application data flow

Once the handshake completes and both peers are validated, the applications begin exchanging encrypted data over the channel.

How do you measure TLS handshake time?

Measure TLS handshake time in Wireshark by isolating each phase of connection setup. Read the gap between the start and end packets of each phase. Work through DNS, TCP, and TLS separately, so you can find the slow phase instead of guessing from a total.

• DNS: Filter with dns and compare the query and response timestamps for resolution time.
• TCP or QUIC: Filter with tcp.flags.syn==1 to find the SYN and SYN-ACK, then measure the gap to the completing ACK.
• TLS: Filter with tls.handshake and, for a full TLS 1.2 handshake, measure from the Client Hello through the server’s Finished message.

Slow or retried DNS shows up before TCP starts. For HTTP/3, the transport is QUIC over UDP, so inspect the QUIC initial packets instead. Wireshark’s “Time since previous frame” column shows each gap directly.

You can also right-click a packet and set it as a time reference to measure between any two messages. A large gap between Client Hello and Server Hello points at the server or the path to it. A long DNS step points somewhere else entirely.

Why does a TLS handshake fail?

A TLS handshake fails when the two peers can’t agree on trusted parameters. It usually ends with a TLS alert and a closed connection. A handful of recognizable patterns cover most cases, and each leaves a clear signature in the capture.

• Certificate errors: The client sees an expired, untrusted, or hostname-mismatched certificate, then sends a TLS alert and closes.
• Unsupported versions or cipher suites: The peers share no version or suite, so the server sends a handshake failure alert.
• SNI problems: The server gets a missing or wrong Server Name Indication, then presents the wrong certificate or rejects the connection.
• TLS alerts: The alert level and description name the reason, such as handshake_failure or bad_certificate.
• Timeouts: The client sends a Client Hello and nothing comes back, or a later message doesn’t arrive.

Version mismatches can occur when a client supports only TLS 1.0 or 1.1, which current TLS requirements prohibit negotiating. To read the alerts, filter with tls.alert_message. An aborted handshake ends with a fatal alert and a connection close, so you can see exactly where it stopped.

How do you separate network delay from server processing?

You separate the two by checking whether the delay comes with TCP retransmissions or with a quiet gap. Wireshark flags retransmissions and duplicate ACKs when you filter with tcp.analysis.retransmission.

Repeated retransmissions or other TCP loss indicators strengthen the case for a network problem. A clean TCP stream with a long gap before the Server Hello can point toward server-side processing, but a client-side capture alone cannot distinguish server processing from delay elsewhere on the path.

Why one capture can’t tell the whole story

A capture from one machine answers one question well: what happened in this session, at this location, at this time. It can’t show whether other users see the same thing, whether the problem repeats, or where along the Internet path the delay occurs.

A slow Server Hello in your capture could be the server, or congestion three hops away that you can’t see from where you’re sitting. A single capture can’t tell you whether the problem repeats, who else it affects, or where on the route it starts. Answering that takes measurement from more than one vantage point.

How do you monitor TLS handshake performance across all users?

Monitor TLS handshake performance across all users by pairing outside-in measurement from multiple vantage points with infrastructure telemetry from your own systems. Wireshark shows what happened in one captured session. Outside-in monitoring shows where, when, and for which users the problem repeats. Infrastructure observability supplies the server, load balancer, network device, and certificate context that explains why.

Running that measurement continuously and on a schedule turns a slow handshake into a trend you can alert on, not a one-off you happened to capture. It also isolates whether the delay sits in the Internet path or inside your own infrastructure. These blind spots grow in hybrid and multi-cloud setups, a recurring theme in cloud monitoring.

Infrastructure monitoring covers the inside view, tracking servers, network devices, and certificates. That supplies the context behind what the outside-in view reports. Together the two turn a one-off capture into an ongoing picture of where problems start and who they hit.

FAQs