Best Solutions for TLS Analysis in 2026

The best solution for TLS analysis in 2026 depends on the job in front of you. For a failed handshake, use Wireshark or TShark on a capture of the failing connection; for security monitoring of encrypted traffic, use Zeek, Suricata, or an NDR platform such as Corelight or ExtraHop RevealX; for application debugging, use authorized session secrets with Wireshark; and for a fleet-wide inventory of TLS versions and certificates, use Zeek logs or a monitoring platform's records.

Our TLS analysis tools guide compares tools by what each one can prove with and without secrets. This article starts from the scenario instead, then names the solution, the first commands to run, and the point where you need a different tool.

Decision table: choose by scenario

If no capture exists yet, start with tcpdump or dumpcap on the affected host, or retrieve packets from a recorder.

Scenario 1: troubleshooting TLS handshake failures

A handshake failure is a sequence question. You need to know where the exchange stopped: before the ClientHello, after the ClientHello, after the ServerHello, during certificate validation, or after the handshake when application data should have started.

Wireshark is the strongest tool here because it shows exact order, timing, alerts, and resets. Start with these display filters:

tls.handshake.type == 1 || tls.handshake.type == 2
tls.alert_message
tcp.flags.reset == 1
tls.handshake.extensions_server_name == "api.example.com"

Then read the failing stream in order. Common patterns include:

• ClientHello followed immediately by a TCP reset, which often points to a middlebox, a listener mismatch, or a server that refuses the offered parameters
• a handshake_failure or protocol_version alert from the server, which suggests no shared version or cipher suite
• an unknown_ca or bad_certificate alert from the client, which points to trust store or chain problems
• ClientHello retransmissions with no response, which is a reachability or filtering question rather than a TLS question

Compare the failing connection with a successful one from a similar client. Differences in offered versions, supported groups, server name, or ALPN often explain the failure faster than reading either connection alone.

For repeatable work, export the same fields with TShark:

tshark -r failing.pcap -Y "tls.handshake.type == 1" \
  -T fields -e frame.number -e ip.src -e ip.dst \
  -e tls.handshake.extensions_server_name \
  -e tls.handshake.extensions.supported_version

When the failure is sparse inside a large capture, or the team needs a written explanation rather than a screen session, PacketSafari Analyzer can correlate DNS, TCP setup, the handshake, alerts, resets, and comparable successes into a finding with exact packet evidence. It works on the selected capture and states which facts remain visible without decryption.

Scenario 2: security monitoring of encrypted traffic

Continuous monitoring is a different job from troubleshooting. You need structured records across many connections, retained over time, with alerts and search.

Zeek writes TLS connection properties to ssl.log, including version, cipher, server name, and whether the session was established. Suricata adds signatures and JA3 or JA4 matching on visible handshake features. Both can process live traffic or PCAP files.

Typical monitoring questions include:

• Which clients connect to rare server names or newly observed certificates?
• Which connections use self-signed or invalid certificate chains?
• Which client fingerprints appear on only one or two hosts?
• Which hosts make regular, small TLS connections to the same destination?

Corelight and ExtraHop RevealX package this kind of analysis for enterprise deployment, with sensors, detections, and integration into SIEM and response workflows. ExtraHop also offers strategic decryption under its own deployment model.

The boundary is the same for all of them: fingerprints and certificate metadata are leads, not verdicts. Legitimate software can share a fingerprint with malicious software, and TLS 1.3 plus Encrypted ClientHello reduce what a passive sensor can see. When an alert needs to become a reviewed conclusion, retrieve the packets and investigate the specific session. The sibling article on how to find malicious traffic in PCAPs lists filters and commands for that step.

PacketSafari is not a monitoring solution. It fits after a monitoring tool has selected a capture worth investigating.

Scenario 3: authorized decryption for application debugging

When the question is about the request or response inside TLS, such as a wrong header, an unexpected status code, or a malformed API call, you need session secrets. A server certificate or its public key is never enough, and an RSA private key does not decrypt TLS 1.3 or TLS 1.2 sessions that use ephemeral key exchange.

The practical method is a key log file from a client or server you are authorized to instrument. Many clients and libraries honor the SSLKEYLOGFILE environment variable, including common browsers and curl builds:

export SSLKEYLOGFILE="$HOME/tls-debug/keys.log"
curl https://api.example.com/health

Capture the traffic at the same time, then decode it with the key log:

tshark -r debug.pcap -o tls.keylog_file:keys.log -Y http2 \
  -T fields -e frame.number -e http2.header.name -e http2.header.value

To keep secrets and packets together for a colleague, Wireshark's editcap can embed them in a PCAPNG:

editcap --inject-secrets tls,keys.log debug.pcap debug-with-keys.pcapng

Treat that file, and the key log, with the same care as the decrypted data. Limit who receives it, delete it when the work is done, and never collect secrets from systems you do not control. Wireshark's TLS wiki page documents the supported methods.

The same key log approach works for QUIC in Wireshark when the client exports its secrets.

Scenario 4: inventory of TLS versions and certificates

Some teams need a compliance-style answer: which systems still negotiate TLS 1.0 or 1.1, which certificates expire soon, and which services present unexpected issuers. This is a reporting task over many connections, so structured logs fit better than a packet workbench.

With Zeek, process a capture or read existing logs:

zeek -C -r segment.pcap local
zeek-cut version < ssl.log | sort | uniq -c | sort -rn
zeek-cut id.resp_h server_name version < ssl.log | grep -E "TLSv10|TLSv11"
zeek-cut certificate.subject certificate.issuer certificate.not_valid_after < x509.log | sort -u

For a single capture without Zeek, TShark can extract the negotiated version from ServerHello messages. Remember that a TLS 1.3 ServerHello carries a legacy version of 0x0303 and signals 1.3 in the supported_versions extension:

tshark -r segment.pcap -Y "tls.handshake.type == 2" \
  -T fields -e ip.src -e tls.handshake.version \
  -e tls.handshake.extensions.supported_version | sort | uniq -c

Two cautions apply. First, a capture only reflects the clients and services that spoke during the capture window, so an inventory from one segment is not an inventory of the estate. Second, TLS 1.3 encrypts the certificate, so passive certificate inventory works mainly for TLS 1.2 and earlier. Active scanning or endpoint configuration review fills that gap. A traffic inventory supports a compliance program; it does not certify one.

Scenario 5: explaining one incident after the fact

Sometimes the question is narrow: why did this API call fail at 09:42? You already have a capture, and the answer must hold up to review. This is the job PacketSafari is designed for. Triage runs capture-wide checks first, the Agent investigates the bounded evidence, and Verification tests the Preliminary Report against exact packets before the Final Report. When authorized secrets are supplied and supported, decrypted protocol evidence joins the investigation. When they are not, the report states where payload-level attribution stops. See investigation workflows for how the fast and full paths differ.

Keep Wireshark close for exact frame review of any disputed claim.

Next steps

1. Name the scenario before choosing a tool. Troubleshooting, monitoring, debugging, inventory, and incident explanation have different inputs and outputs.
2. Confirm what visibility you have: capture location, both directions, TLS versions in use, and whether authorized secrets exist.
3. Build a small test set with a successful TLS 1.2 session, a successful TLS 1.3 session, a failed handshake, a reset before application data, and a QUIC connection.
4. Run each candidate solution against that set and record what it shows with and without secrets.
5. Decide where packets will be retained, so a monitoring lead can become an investigated session.