JA3 / JA4 Fingerprinting

JA3 / JA4 Fingerprinting are techniques that build a stable “fingerprint” of a TLS client or server from the way it negotiates an encrypted connection. The fingerprint comes from the cleartext, not-yet-encrypted fields of a connection’s first packets — ClientHello and ServerHello (TLS version, cipher list, extensions, supported curves, ALPN). That lets you recognise an application type, the TLS library in use, or a malware family without decrypting the connection’s content. JA3 was created at Salesforce, and JA4+ — its successor — at FoxIO.

How does TLS fingerprinting work?

Every TLS connection opens with a short “opening exchange” (the handshake), which still travels in plain text. The client sends a ClientHello packet declaring which protocol versions it supports, its list of ciphers (cipher suites), its extensions and curves, and the application protocol it wants to negotiate (ALPN — Application-Layer Protocol Negotiation). All of this is visible before any session key exists.

Each TLS implementation — browser, library, agent, or tool — arranges these values in its own slightly different, characteristic way. A TLS fingerprint is simply a hash of that combination. It is a bit like recognising someone by how they speak rather than by what they say: the same type of client produces the same fingerprint no matter which IP address, port, or certificate it connects to.

How is JA3 computed?

JA3 builds the fingerprint from the ClientHello packet. Numeric values are pulled from its fields and joined into one string, always in the same order:

1. TLS version,
2. list of ciphers (cipher suites),
3. list of extensions,
4. supported elliptic curves,
5. elliptic curve point formats.

Fields are separated by commas and values within a field by hyphens, e.g. 769,47-53-5-10-...,0-23-65281-10-11-...,29-23-24,0. That string is hashed with MD5, producing a 32-character fingerprint. GREASE values (a mechanism from RFC 8701 that deliberately injects “random” entries) are skipped, so clients that use them still yield a stable hash. The server-side counterpart is JA3S, computed from the ServerHello packet (version, chosen cipher, extensions).

How is JA4 computed and what does the JA4+ suite cover?

JA4 is a newer version of the ClientHello fingerprint, designed to be human-readable and more resilient to changes in clients. It has a three-part format, a_b_c:

• Part a — readable metadata: protocol (t for TLS over TCP, q for QUIC, d for DTLS), TLS version (e.g. 13), whether a domain name (d) or an IP address (i) was given, the cipher count, the extension count, and two characters from the first ALPN.
• Part b — a 12-character truncated SHA256 hash of the sorted cipher list.
• Part c — a 12-character truncated SHA256 hash of the sorted extension list (excluding SNI and ALPN) together with the list of signature algorithms.

The most important difference from JA3: JA4 sorts ciphers and extensions, so a randomised extension order no longer breaks the fingerprint. JA4+ is a whole suite of fingerprints for different protocols and layers, including JA4 (TLS client), JA4S (TLS server response), JA4H (HTTP headers), JA4L (location/latency), JA4X (X.509 certificates), and JA4T and JA4SSH. The parts can be combined and searched in fragments (e.g. just a and c), which helps with threat hunting — actively looking for threats in traffic.

How does JA3 differ from JA4?

• Format: JA3 is a single 32-character MD5 hash; JA4 is a readable a_b_c string with explicit metadata and truncated SHA256 hashes.
• Field order: JA3 depends on the order of extensions in the ClientHello; JA4 sorts them, so randomisation does not bother it.
• Scope: JA3 covers only TLS over TCP; JA4 distinguishes TCP, QUIC, and DTLS, and the full JA4+ suite also covers HTTP, certificates, and SSH.
• Readability: JA3 is just a hash and reveals nothing; JA4 shows some traits (protocol, version, SNI, ALPN) directly.

Why do JA3/JA4 matter for security?

Almost all of today’s network traffic is encrypted, so classic packet inspection sees little without decryption. TLS fingerprinting wins back some of that visibility, because it works on the cleartext handshake metadata — it never looks inside the content. In practice it is used for a few things:

• Detecting malware and C2 channels (Command and Control — remote control of infected machines): many malware families use specific TLS libraries and so produce a characteristic fingerprint, recognisable despite changing IPs, domains, or certificates. Combining the client and server fingerprints (JA3+JA3S or JA4+JA4S) improves accuracy, because it describes the whole negotiation pair.
• Traffic classification and anomaly detection: fingerprints help group clients, catch a mismatch between a declared User-Agent and the actual TLS stack, and tell bots and scanners apart from ordinary browsers.
• Enriching telemetry for SOC, NDR, and SIEM: a fingerprint as an extra flow attribute makes it easier to correlate events, search through history, and write detection rules.

In the Pyramid of Pain model (which ranks attack indicators by how much they hurt an attacker to swap out), a TLS negotiation fingerprint is harder to change than an IP address or a file hash, so it raises the attacker’s cost. The technique pairs well with Encrypted Traffic Analysis (ETA) — analysis of encrypted traffic that infers the nature of a connection from metadata and statistical features without decrypting it.

What are the limitations of JA3/JA4?

• Extension randomization: since Chrome 110 and Firefox 114, browsers randomise the order of TLS extensions, so the same client can produce different JA3 hashes — which made JA3 unstable. JA4 fixes this by sorting.
• Collisions and lack of uniqueness: a fingerprint points to an implementation or library, not to a specific computer or person; different applications built on the same library can share a fingerprint.
• Spoofing: attackers can deliberately mimic the ClientHello of a popular browser (TLS mimicry) to hide their tool behind a known, “innocent” fingerprint.
• A cleartext handshake is required: Encrypted ClientHello (ECH) encrypts part of the ClientHello packet, leaving less data for the fingerprint.
• A hint, not a verdict: a fingerprint on its own is a signal, not proof — it has to be combined with others (reputation, volume, regular “knocking” on a server, i.e. beaconing).

Learn more

• Cyber Kill Chain — JA3/JA4 can help detect attacker infrastructure during delivery, command, and control stages.
• Asset Discovery — JA3/JA4 helps identify devices and services by observing their TLS client fingerprints.
• Network Forensics — JA3/JA4 fingerprints support traceability of TLS sessions in network forensic investigations.
• NSM (Network Security Monitoring) — JA3/JA4 adds TLS fingerprinting to NSM for detecting suspicious or known-malicious clients.
• Data Loss Prevention (DLP) — JA3/JA4 can help spot encrypted exfiltration by identifying unusual TLS client behavior.
• Firewall / NGFW — JA3/JA4 fingerprints can inform firewall rules by identifying known TLS client patterns.
• Intrusion Detecting System — JA3/JA4 improves intrusion detection by matching TLS fingerprints against threat intel.
• Resource Hijacking — JA3/JA4 can reveal cryptomining malware through its characteristic TLS client fingerprint.