TLS Fingerprinting (JA4)

JA4 generates a compact fingerprint by concatenating and hashing specific TLS Client Hello fields: TLS version, cipher suites, extensions, and elliptic curves. Unlike its predecessor JA3, JA4 uses a truncated SHA-256 hash that produces a consistent 12-character fingerprint regardless of input length. The algorithm sorts cipher suites and extensions alphabetically before hashing to ensure deterministic output across different client implementations.

• Format: JA4=tls_version+cipher_hash+ext_hash+curve_hash
• Consistency: Identical TLS stacks always produce identical fingerprints
• Collision resistance: SHA-256 prevents fingerprint collisions between different clients

Beyond the base JA4 fingerprint, the JA4+ suite provides additional fingerprinting dimensions for comprehensive client identification. JA4S fingerprints the server's TLS Server Hello response, capturing the server's chosen cipher suite and extensions. JA4H fingerprints HTTP/2 and HTTP/3 session parameters. JA4X captures X.509 certificate attributes. JA4SSH extends the methodology to SSH protocol negotiation.

• JA4S: Server-side TLS fingerprinting for detecting spoofed servers
• JA4H: HTTP/2 SETTINGS frame and pseudo-header order analysis
• JA4X: TLS certificate issuer, validity period, and extension profiling
• JA4SSH: SSH key exchange algorithm and cipher negotiation fingerprinting

JA4 fingerprints integrate directly into packet capture analysis and flow monitoring tools without requiring decryption of TLS traffic. Since the Client Hello is sent in cleartext before the encrypted tunnel is established, JA4 generation works on passive network observations. This enables Zeek, Suricata, and Wireshark plugins to tag sessions with JA4 hashes for threat hunting and anomaly detection.

• Passive monitoring: No TLS decryption required; Client Hello is unencrypted
• Zeek integration: Native JA4 scripting for real-time connection logging
• Threat hunting: Identify C2 malware families by their distinctive TLS fingerprints
• Flow correlation: Link encrypted sessions to specific applications without deep packet inspection

JA4 addresses critical limitations of the legacy JA3 fingerprinting method. JA3 used MD5 hashing, which is vulnerable to collision attacks and produces unnecessarily long 32-character hashes. JA4 switches to truncated SHA-256 for security and brevity. JA4 also introduces GREASE detection — it identifies and ignores randomized TLS extension values that browsers inject to prevent protocol ossification, which JA3 incorrectly treated as unique fingerprint components.

• Hash function: JA3 uses MD5; JA4 uses SHA-256
• GREASE handling: JA4 automatically filters randomized extension values
• Fingerprint length: JA3 produces 32 chars; JA4 produces 12 chars
• Protocol support: JA4 natively supports TLS 1.3, while JA3 was designed for TLS 1.2
• Backward compatibility: JA4 includes a JA3 compatibility mode for legacy systems

JA4 fingerprinting is deployed at the CDN edge or reverse proxy layer to classify incoming traffic before it reaches origin servers. Combined with IP reputation and behavioral analysis, JA4 provides a hard-to-spoof signal for bot scoring. Enterprise implementations typically maintain a fingerprint allowlist for legitimate browser versions and a denylist for known automation tooling TLS signatures.

• Edge deployment: Integrate with HAProxy, NGINX, or cloud WAF solutions
• Fingerprint database: Maintain versioned signatures for Chrome, Firefox, Safari, and Edge releases
• Correlation engine: Combine JA4 with JA4H and JA4S for multi-layer verification
• False positive mitigation: Allowlist legitimate enterprise TLS-terminating proxies and API clients

The predecessor to JA4, JA3 generates an MD5 hash from five parameters of the TLS Client Hello: TLS version, accepted cipher suites, list of extensions, elliptic curves, and elliptic curve point formats. While widely adopted in threat hunting and Zeek integrations, JA3 suffers from hash collisions and cannot distinguish between clients that negotiate different ALPN protocols. JA4 improves upon this by incorporating ALPN and using a more collision-resistant hashing methodology.

JA4 is the foundational fingerprint in a family of network traffic identification methods that extend beyond the Client Hello. The suite includes:

• JA4S: Server Hello fingerprint, capturing the server's cipher selection and extensions
• JA4H: HTTP/2 fingerprint based on SETTINGS frame order and values
• JA4X: X.509 certificate fingerprint derived from issuer and subject fields
• JA4SSH: SSH session fingerprint from key exchange algorithm negotiation This multi-protocol approach enables end-to-end session correlation even when traffic is proxied or decrypted.

The unencrypted initial packet sent by a client to initiate a TLS handshake. It advertises the client's capabilities including supported cipher suites, TLS protocol version, compression methods, and extensions such as Server Name Indication (SNI) and Application-Layer Protocol Negotiation (ALPN). Because this packet is sent in cleartext before encryption is established, it provides a rich, observable signature that JA4 captures and hashes. Different TLS libraries (OpenSSL, BoringSSL, NSS, Go crypto/tls) produce distinct Client Hello structures.

Application-Layer Protocol Negotiation is a TLS extension that allows the client to advertise which application protocols it supports (e.g., h2 for HTTP/2, http/1.1, h3 for HTTP/3). The server selects one from the list. JA4 incorporates the ALPN value as a critical differentiator, enabling it to distinguish between a browser negotiating HTTP/2 and a Python requests library negotiating only HTTP/1.1—a distinction JA3 could not make. This is essential for identifying headless browsers and API clients masquerading as legitimate traffic.

Generate Random Extensions And Sustain Extensibility is a protocol hardening technique defined in RFC 8701. Clients inject random, invalid values into TLS extensions, cipher suite lists, and ALPN advertisements to prevent servers from developing brittle, hardcoded assumptions about specific implementations. JA4 must correctly handle GREASE values by ignoring them during hash computation. A client that does not implement GREASE—common in custom scripts and older libraries—produces a more stable, identifiable fingerprint that stands out from browser traffic.

A complementary technique to TLS fingerprinting that analyzes TCP/IP stack attributes in passively observed packets to identify the connecting host's operating system. Key signals include:

• Initial TTL value: Windows uses 128, Linux uses 64
• TCP window size: Varies by OS and version
• Don't Fragment (DF) flag behavior
• TCP option ordering and timestamps Combined with JA4, passive OS fingerprinting creates a multi-layer identification matrix that can detect mismatches—such as a Linux TLS stack advertising a Windows TCP signature, indicating a proxy or spoofed environment.