tshark: TLS metadata while the payload stays opaque

What you can see without a key

tls.handshake.type==1 is a Client Hello. The server name extension is tls.handshake.extensions_server_name, the name the client sent in the clear so a load balancer can pick a certificate. That name is not proof of which certificate the server presented. It is proof of which name the client requested.

The server certificate and the negotiated version are on the server side of the handshake. Handshake type 11 is the certificate message. The copyable command prints that message's summary so you can compare the name with the runbook. Attribute names inside the certificate vary by Wireshark version, so confirm them with tshark -G fields before you add an -e. The records after the handshake are application data. Treat them as opaque. A field that would have been an HTTP path in cleartext is empty here, and that emptiness is the control working.

• Client Hello is handshake type 1. Server Hello is type 2.
• SNI is a name, not an authorization decision.
• An old version or a certificate subject the runbook does not list is a lab change to file.
• Do not take a production private key to read a lab capture, and do not take a lab key anywhere else.

A key log the owner already handed you

Some lab applications can write a TLS key log for troubleshooting. If the owner includes that file in the case, tshark can be pointed at it and the cleartext becomes available for that capture. The manual and Wireshark's TLS preferences document the preference. Using it is a scope decision about a secret the owner gave you.

This course does not tell you how to obtain a key. If the case has no key log, you stop at metadata and you use the application log for paths and status codes. A key log is handled like the pcap: case folder, named people, deletion date.

A worked defensive case

The DNS lesson found that files.lab.internal resolved to 10.8.0.77 instead of 10.8.0.40. You extract Client Hello names from the web tier. The table shows 10.8.0.20 sending SNI files.lab.internal toward 10.8.0.77:443. Handshake type 11, the certificate message, summarizes a certificate whose name is the lab's old staging name.

The ticket now has three agreeing facts: the DNS answer, the name the client requested, and the certificate subject. The change is the DNS record and the certificate on the staging VM. You never decrypt the session. The status code still comes from the service log.

Where this is documented

tshark field tls.handshake.extensions_server_name and tls.handshake.type are part of the TLS dissector. Older notes say ssl. for the same fields. On a current build, prefer the tls. names, and check tshark -G fields if a name is refused.

Use a host-only lab network, or a capture the owner already handed you. These commands read that file or record a single lab host. They are not a scan of the public internet.

Commands

tshark -r /lab/evidence.pcap -Y 'tls.handshake.type==1' -T fields -E header=y -e ip.src -e ip.dst -e tcp.dstport -e tls.handshake.extensions_server_name

tshark -r /lab/evidence.pcap -Y 'tls.handshake.type==11' -T fields -E header=y -e frame.number -e ip.src -e _ws.col.info