JA3 and JA4 fingerprints: what they are and how to get them from a PCAP

Encryption hides what a client says, but not how it starts talking. The first message of every TLS connection lists the client's capabilities in an order that depends on its software. Hash that list and you get a fingerprint that recognises the program behind a connection, whatever address or server name it uses.

1. What a TLS fingerprint captures

A TLS connection starts with a ClientHello. It is sent before encryption begins, and it lists the TLS versions, cipher suites, extensions, key-exchange groups, signature algorithms and application protocols (ALPN, such as h2) the client supports. Each TLS library fills these in its own way, so the list identifies the client software, often down to the version:

• A browser, an operating system's own TLS stack, curl, a Python or Go script, or a piece of malware with its own TLS code each produce their own fingerprint.
• The fingerprint follows the software, not the address. It still matches when malware moves to a new server or domain.
• It identifies software, not people or devices. Every copy of the same browser version gives the same fingerprint.

Servers can be fingerprinted from their reply as well (JA3S, JA4S), and SSH clients and servers from their key-exchange message (HASSH).

2. JA3 vs JA4

JA3 (Salesforce, 2017) joins the version, ciphers, extensions, groups and point formats as decimal numbers, in the order the client sent them, and takes the MD5 hash. It became the common currency of threat-intel feeds.

Since early 2023, Chrome and the browsers built on it have randomised the order of their TLS extensions on every connection. Because JA3 keeps the order, the same browser now produces a different JA3 almost every time. In one home-browsing capture we checked, 587 ClientHellos produced 243 different JA3 hashes.

JA4 (FoxIO, 2023) sorts the ciphers and extensions before hashing, so it stays stable. The same 587 ClientHellos produced 22 JA4 fingerprints. JA4 is also partly readable:

t13d1517h2_8daaf6152771_b6f405a00624
│ │ │ │ │  │            └ hash of the sorted extensions + signature algorithms
│ │ │ │ │  └ hash of the sorted cipher suites
│ │ │ │ └ first application protocol offered (h2 = HTTP/2)
│ │ │ └ 15 cipher suites, 17 extensions
│ │ └ d = a server name (SNI) was sent; i = none
│ └ highest TLS version offered (1.3)
└ t = TLS over TCP; q = QUIC

Use JA4 for anything new, and keep JA3 for matching older intelligence. A JA3 from a modern browser is close to useless on its own.

3. Extract fingerprints from a capture

Current Wireshark versions compute both fingerprints natively; these commands were run with tshark 4.6. List each ClientHello with its client, server name and fingerprints:

tshark -r capture.pcapng -Y "tls.handshake.type == 1" \
  -T fields -e ip.src -e tls.handshake.extensions_server_name \
  -e tls.handshake.ja4 -e tls.handshake.ja3

Count how often each JA4 appears, most common first:

tshark -r capture.pcapng -Y "tls.handshake.type == 1" \
  -T fields -e tls.handshake.ja4 | sort | uniq -c | sort -rn

Then find every connection made by one fingerprint, in Wireshark or tshark:

tls.handshake.ja4 == "t13d1517h2_8daaf6152771_b6f405a00624"

In Wireshark, expand a ClientHello, right-click the JA4 field and choose Apply as Column to see fingerprints alongside every connection. QUIC ClientHellos are matched by the same filter, because Wireshark decrypts QUIC Initial packets; their JA4 starts with q. The related fields are tls.handshake.ja3s for servers and ssh.kex.hassh / ssh.kex.hasshserver for SSH.

4. Read the results

On a typical network, a handful of fingerprints account for most connections: the deployed browsers, the operating system's TLS library, and a few agents. The interesting entries are at the bottom of the count:

• A rare fingerprint on one host. A script, a newly installed tool, or something unwanted. Check which server names it contacted and when.
• A fingerprint you can't match to deployed software. Compare it with known browsers and agents. Public JA4 databases can name common clients; look them up by hand, as the capture itself never needs to leave your network.
• A browser-like server name with a non-browser fingerprint. Software connecting to a popular service doesn't make it the official app.
• Old capabilities. A JA4 offering at most TLS 1.2 (t12), or very few ciphers, often points to embedded devices or outdated libraries.

Once you know a fingerprint is bad, it becomes an indicator. It keeps matching after the attacker changes infrastructure, until they change their TLS code.

5. Know the limits

• Shared libraries share fingerprints. Many tools built on the same language runtime look identical, so a Go or Python fingerprint alone doesn't separate a legitimate tool from malware written in the same language.
• Fingerprints change with updates. A browser release can change its JA4. Expect drift, and refresh your baselines.
• They can be imitated. Libraries exist to make a client mimic a browser's ClientHello. A common fingerprint is weak evidence of innocence.
• Intercepting proxies hide the client. Behind a TLS-inspecting proxy, the server side sees the proxy's fingerprint, and captures taken there do too.
• You need the start of the connection. A capture that begins mid-session has no ClientHello to fingerprint.

Manual method vs PCAPNG Analyzer