Analyze a TLS Handshake with Wireshark

Wireshark can show where a TLS connection is failing: before a ClientHello, during negotiation, or after an alert or TCP reset. This guide captures one HTTPS request and uses display filters to inspect the handshake. It complements the site’s DNS and TCP triage guide by focusing on TLS messages.

Capture only authorized traffic

Packet captures can contain internal addresses, hostnames, and sensitive application data. Store and share them carefully. TLS 1.3 encrypts much of the handshake after ServerHello, and Encrypted ClientHello (ECH) can hide the real server name; a normal capture will not always expose a certificate or hostname.

---

01

Prepare One Reproducible HTTPS Request

Capture Setup

Use a test host or service you administer and record its hostname and the time of the test. In Wireshark, open the Capture Options dialog, select the interface that carries the traffic, and start a short capture. Avoid capturing on a shared production link unless approved.

Test request: HTTPS to a controlled host
Capture interface: active client interface
Start capture, then generate the request in a separate terminal:

curl -I https://example.com/

❯ Illustrative Output (Results Vary)

Example request result:
HTTP/2 200
The actual status and negotiated protocol depend on the server and client.

---

02

Use Display Filters on the Completed Capture

Filter

Stop the capture after the test request finishes. Display filters do not remove packets from the saved capture; they only change what is shown. Start with TLS handshake messages, then narrow to the test host or port if the capture contains unrelated traffic.

tls.handshake

tcp.port == 443 && tls.handshake

❯ Illustrative Output (Results Vary)

Visible packets should include the client and server handshake messages
for the controlled connection, when captured at a suitable point.

---

03

Check SNI, ALPN, and Supported Versions

ClientHello

Select a ClientHello packet and expand the Transport Layer Security details pane. The fields below help confirm which hostname and application protocols the client offered. The Server Name Indication field may be absent or concealed when ECH is in use.

tls.handshake.type == 1
tls.handshake.extensions_server_name
tls.handshake.extensions_alpn_str
tls.handshake.extensions.supported_version

❯ Illustrative Output (Results Vary)

ClientHello
    Server Name: example.com (if visible)
    ALPN: h2, http/1.1 (example values)
    Supported Versions: inspect the offered list

---

04

Trace the Handshake in Packet Order

Troubleshoot

Use the packet list and sequence numbers to see whether the server responded, which TLS version was selected, and whether the connection ended with an alert or TCP reset. The exact messages vary by TLS version, resumption, and capture location. Do not interpret missing encrypted handshake details as proof that the server sent no certificate.

tls.handshake.type == 2
tls.alert_message
tcp.flags.reset == 1
tcp.analysis.retransmission

❯ Illustrative Output (Results Vary)

ClientHello -> ServerHello -> remaining handshake data or alert
If no server response appears, also check the TCP path and capture point.

---

05

Record the Result and Protect the Capture

Closeout

Record the Wireshark version, interface, test time, display filter, and relevant packet numbers. Save the capture only when needed for the investigation, restrict access, and follow the organization’s retention and deletion rules. If TLS decryption is required in an authorized lab, use a dedicated test client key log and protect it like a credential.

Capture file: tls-test.pcapng
Related filter: tls.handshake
Sensitive data review: complete before sharing

❯ Illustrative Output (Results Vary)

Finding: summarize the last successful handshake message and observed error
Next action: validate the relevant client, server, or network configuration

References

Use Wireshark’s current TLS display filter reference and display filter guide to confirm field names for the version you are running.