What is JA4 TLS fingerprinting and how does it differ from JA3?

JA4 is the next generation of TLS client fingerprinting, created by John Althouse (who also created JA3). While JA3 generates a single MD5 hash of the TLS ClientHello message — combining cipher suites, extensions, elliptic curves, and point formats into one opaque string — JA4 produces a structured, human-readable fingerprint with distinct sections. The JA4 hash format is: TLS version + SNI presence + number of ciphers + number of extensions + ALPN value, followed by a truncated SHA256 of sorted cipher suites and a truncated SHA256 of sorted extensions with signature algorithms. The sorting makes JA4 more stable across client library updates where only the ordering changes, and the readable prefix lets analysts immediately understand what type of client produced the fingerprint without needing a lookup database.

How do CDN edge servers use JA4 fingerprints for bot detection?

CDN edge servers extract the JA4 fingerprint from every TLS handshake before any HTTP data is exchanged. The fingerprint is compared against a database of known fingerprints — legitimate browsers produce specific JA4 hashes that are well-documented, while automated tools like curl, Python requests, Go's net/http, and headless browsers each produce distinctive fingerprints. When a client claims to be Chrome 120 via its User-Agent header but presents a JA4 fingerprint matching Python's urllib3, the CDN flags this as a likely bot. This detection happens at the TLS layer, before the HTTP request is processed, giving the edge server the earliest possible signal that the client is not what it claims to be.

What are the different JA4 sub-fingerprints (JA4S, JA4H, JA4X)?

The JA4 suite includes multiple fingerprint types that together build a comprehensive client profile. JA4 fingerprints the client's TLS ClientHello message. JA4S fingerprints the server's TLS ServerHello response, identifying which cipher suite and extensions the server selected. JA4H fingerprints the HTTP client by hashing the HTTP headers, their order, and their values — capturing how the client constructs HTTP requests beyond the TLS layer. JA4X fingerprints X.509 certificates by hashing issuer and subject fields. JA4T fingerprints TCP connection characteristics like window size, TTL, and options. Together, these create a multi-layer identity profile that is extremely difficult for bots to forge because they would need to match legitimate client behavior at every protocol layer simultaneously.

Can sophisticated bots evade JA4 fingerprinting?

Sophisticated bots can partially evade JA4 by using TLS libraries configured to mimic real browsers — tools like curl-impersonate and tls-client modify the TLS ClientHello to match Chrome or Firefox fingerprints. However, JA4's multi-layer approach makes full evasion much harder than with JA3. Even if a bot matches the JA4 TLS fingerprint perfectly, the JA4H HTTP fingerprint often reveals discrepancies in HTTP header ordering, capitalization, or the presence of headers that the claimed browser would never send. The JA4T TCP fingerprint adds another layer by checking operating system-level TCP characteristics. A bot would need to simultaneously forge TLS, HTTP, TCP, and certificate fingerprints — matching each to a consistent, plausible client profile — which dramatically increases the complexity and cost of evasion.

How does JA4 fingerprinting impact CDN performance?

JA4 fingerprint extraction adds negligible overhead to the TLS handshake — typically under 50 microseconds per connection. The fingerprint is computed from data the CDN edge server already processes during the TLS handshake (cipher suites, extensions, ALPN values), so no additional network round trips are required. The fingerprint lookup against the database uses an in-memory hash table with O(1) average lookup time. For high-traffic CDN nodes processing millions of TLS handshakes per second, the JA4 computation adds less than 0.1% CPU overhead. The fingerprint can be cached per connection and reused for all subsequent HTTP requests on that connection, amortizing even this minimal cost across multiple requests.

JA4 TLS Fingerprinting: Identifying Clients at CDN Edge Servers

October 1, 2026 · James Thornton · 12 min read

Every TLS handshake reveals more about a client than just its encryption capabilities. The specific combination of cipher suites, extensions, supported groups, and signature algorithms in a ClientHello message creates a fingerprint as distinctive as a human thumbprint. JA4, the successor to the widely adopted JA3 fingerprinting method, transforms these TLS handshake parameters into a structured, human-readable hash that CDN edge servers use to identify client software, detect bots masquerading as browsers, and enforce security policies before a single byte of HTTP data is exchanged.

The Evolution from JA3 to JA4

JA3, created by John Althouse, Jeff Atkinson, and Josh Atkins at Salesforce in 2017, pioneered passive TLS client fingerprinting by generating an MD5 hash from the ClientHello's TLS version, cipher suites, extensions, elliptic curves, and elliptic curve point formats. The approach was revolutionary — security teams could identify malware, bots, and unauthorized clients purely from their TLS behavior without decrypting traffic or inspecting payloads.

But JA3 had limitations that became apparent at CDN scale. The MD5 hash was opaque: e7d705a3286e19ea42f587b344ee6865 reveals nothing about the client without consulting a lookup database. Minor changes in cipher suite ordering — common between browser point releases — produced completely different hashes, creating fingerprint fragmentation. And as TLS 1.3 reduced the visible cipher suite list to just a few standardized options, JA3 fingerprints became less distinctive, with many different clients producing identical hashes.

JA4 addresses all three problems. Its fingerprint format is structured and readable: t13d1516h2_8daaf6152771_b0da82dd1658. The first section (t13d1516h2) encodes the TLS version (1.3), whether SNI is present (d for domain), the number of cipher suites (15), the number of extensions (16), and the ALPN value (h2 for HTTP/2). The second and third sections are truncated SHA256 hashes of the sorted cipher suites and sorted extensions respectively. Sorting eliminates order-dependent fragmentation, and the readable prefix gives immediate context to anyone analyzing the fingerprint.

How JA4 Fingerprint Construction Works

When a client initiates a TLS connection to a CDN edge server, the edge server receives the ClientHello message as the first packet in the TLS handshake. The JA4 fingerprint is computed from this message using a deterministic algorithm that produces identical output for identical ClientHello parameters regardless of field ordering.

Performance Comparison: Edge vs Origin Processing
Metric	Edge Processing	Origin Processing	Improvement
Latency (p50)	8–15 ms	120–300 ms	15–20x faster
Cache Hit Ratio	85–95%	N/A	Reduces origin load
TLS Handshake	1–5 ms (nearby PoP)	50–150 ms	10–30x faster
Bandwidth Cost	$0.01–0.04/GB	$0.05–0.12/GB	3–5x cheaper
Availability	99.99% (multi-PoP)	99.9% (single DC)	10x fewer outages

The construction process follows these steps:

Section A encodes the protocol context in a human-readable string. The first character indicates the protocol: t for TCP-based TLS, q for QUIC, d for DTLS. The next two characters encode the TLS version (13 for TLS 1.3, 12 for 1.2). A single character indicates SNI presence: d if a domain is present, i if only an IP address is used. Two-digit counts of cipher suites and extensions follow, then the first and last characters of the ALPN value (h2 becomes h2, http/1.1 becomes h1).

Section B sorts the cipher suite values numerically, concatenates them with commas, and computes a truncated SHA256 hash (first 12 characters). The sorting ensures that two clients offering the same cipher suites in different orders produce identical Section B values, solving JA3's fragmentation problem.

Section C applies the same sorted-hash approach to the extension types, appending the signature algorithms as an additional differentiator. This captures the full extension set including supported groups, key share types, and PSK modes that distinguish modern TLS 1.3 clients from each other.

The JA4 Fingerprint Suite

JA4 is not a single fingerprint but a suite of complementary fingerprints, each capturing a different protocol layer. Together, they create a multi-dimensional client profile that makes evasion significantly harder than spoofing any single layer.

JA4S: Server Hello Fingerprint

JA4S captures the server's TLS response — the ServerHello message. This fingerprint records which cipher suite the server selected, which extensions it included, and the ALPN protocol it chose. JA4S is useful for identifying CDN edge servers themselves, detecting TLS-terminating proxies in the request path, and identifying misconfigured servers that select weak cipher suites. When correlated with JA4, the JA4+JA4S pair reveals both ends of the TLS negotiation.

JA4H: HTTP Client Fingerprint

JA4H moves above the TLS layer to fingerprint the HTTP client's behavior. It hashes the HTTP header names (in order), their values, and the Cookie header separately. Each HTTP client constructs requests with characteristic header ordering: Chrome sends headers in a different order than Firefox, and both differ from curl or Python's requests library. A bot using a legitimate Chrome JA4 TLS fingerprint but sending HTTP headers in Python's order is immediately flagged by the JA4H mismatch.

JA4T: TCP Fingerprint

JA4T fingerprints the TCP connection parameters visible in the SYN packet: window size, maximum segment size (MSS), window scale factor, and TCP options ordering. These parameters are set by the operating system's network stack, not by application-level code, making them extremely difficult for bots to forge without kernel-level modifications. A bot running on a Linux VPS claiming to be a macOS Safari user will have Linux TCP characteristics that contradict the claimed identity.

JA4X: X.509 Certificate Fingerprint

JA4X fingerprints the TLS certificates presented during mutual TLS authentication. It hashes the certificate's issuer and subject fields, identifying the certificate authority and the certificate's organizational identity. This fingerprint helps detect forged or self-signed certificates used by malware or unauthorized clients in mTLS environments.

Bot Detection with JA4 at CDN Scale

The primary application of JA4 at CDN edge servers is bot detection. The detection model compares the client's declared identity (User-Agent header) against its actual identity (JA4 fingerprint suite) and flags inconsistencies.

The detection pipeline operates in three stages:

Stage 1: Fingerprint Extraction. During the TLS handshake, the edge server's TLS termination layer (typically OpenSSL, BoringSSL, or a Rust-based TLS library) extracts the ClientHello parameters and computes the JA4 fingerprint. This computation happens inline with the handshake, adding negligible latency. The fingerprint is attached to the connection context and available to all subsequent processing layers.

Stage 2: Database Correlation. The extracted JA4 fingerprint is compared against an in-memory database of known fingerprints. CDN providers like Cloudflare, Fastly, and Akamai maintain continuously updated fingerprint databases built from their global traffic observation. These databases map JA4 hashes to known client software: browsers, mobile apps, API clients, bots, and malware families.

Stage 3: Identity Verification. The database match is compared against the client's claimed identity in the HTTP layer. A request claiming to be Chrome 120 (via User-Agent) but presenting a JA4 fingerprint matching Go's net/http library is an identity mismatch. The bot management engine scores this mismatch along with other signals: request rate, behavioral patterns, IP reputation, and threat intelligence data.

Implementing JA4 at the Edge

CDN edge servers implement JA4 extraction at the TLS termination layer, which means the fingerprint is available before any HTTP processing begins. This positioning gives the edge server the earliest possible detection signal.

For nginx-based edge servers, JA4 extraction integrates as a module that hooks into the SSL handshake callback. The module populates nginx variables ($ja4, $ja4s) that downstream configuration blocks reference for rate limiting decisions, WAF rule evaluation, and access logging. The fingerprint persists for the lifetime of the TLS connection, so HTTP/2 multiplexed requests on the same connection share a single JA4 computation.

At edge function platforms, JA4 data is typically exposed as a request property. Cloudflare Workers, for example, surface the JA4 fingerprint through the cf.botManagement object, allowing edge function code to implement custom logic based on client identity. A WAF rule might block all requests where the JA4 fingerprint indicates Python's requests library but the User-Agent claims to be a browser, while allowing authenticated API clients using Python with proper API keys.

Evasion Techniques and Countermeasures

Sophisticated bot operators are aware of TLS fingerprinting and employ evasion techniques. The most common approach uses libraries like curl-impersonate or tls-client that modify the TLS stack to mimic legitimate browser fingerprints. These tools configure OpenSSL or BoringSSL with the exact cipher suites, extensions, and parameters that Chrome or Firefox would present, producing a JA4 fingerprint indistinguishable from the real browser.

The JA4 suite's multi-layer approach counters single-layer evasion. Even when the JA4 (TLS) fingerprint matches Chrome, the JA4H (HTTP) fingerprint often reveals the deception. Chrome sends HTTP headers in a specific order: Host, Connection, sec-ch-ua, sec-ch-ua-mobile, sec-ch-ua-platform, Upgrade-Insecure-Requests, User-Agent, Accept, and so on. Curl-impersonate matches the TLS layer but may not match this exact HTTP header sequence, producing a JA4H fingerprint that does not correspond to any known Chrome version.

The JA4T TCP fingerprint adds a third dimension. A bot running on a Linux cloud VPS presents Linux TCP window sizes, MSS values, and TTL values — even when the JA4 and JA4H fingerprints match macOS Safari. A real Safari user connects from macOS, which has distinctly different TCP stack parameters. Matching all three layers simultaneously requires the bot to modify kernel-level TCP parameters, which is possible but significantly increases the operational complexity and cost of running the bot infrastructure.

CDN providers complement JA4 with behavioral analysis. A client with a perfect Chrome JA4 fingerprint suite but accessing 500 pages per minute, never loading CSS or images, and never executing the inline analytics beacon clearly behaves unlike a real browser user. JA4 provides the static identity check; behavioral analysis provides the dynamic intent check. The combination produces false positive rates below 0.01% for enterprise CDN deployments.

JA4 and Zero Trust Architecture

In a zero trust architecture, JA4 fingerprinting serves as a device posture signal. The edge BFF or API gateway evaluates the JA4 fingerprint alongside the authentication token, device certificate, and request context to make per-request authorization decisions.

A zero trust CDN policy might specify: "Allow access to /api/admin/* only when the JA4 fingerprint matches a known corporate browser, the JA4T fingerprint matches a corporate-provisioned device OS, and a valid MFA-backed session token is present." This policy enforces device compliance at the edge — a stolen token used from a non-corporate device with a different JA4T fingerprint is rejected, even though the token itself is valid.

For AI agent and machine-to-machine communication, JA4 helps distinguish authorized automation from unauthorized scraping. Authorized API clients present known JA4 fingerprints that match their registered client profiles. An API key issued to a Python application should present a Python JA4 fingerprint; if the same key appears with a Go fingerprint, the CDN flags potential key theft and can trigger step-up verification or key rotation.

Privacy and Compliance Considerations

JA4 fingerprinting operates on network protocol metadata, not on content. The fingerprint is derived from the TLS handshake, which occurs before any application data is exchanged and does not require decrypting user traffic. This positions JA4 as a privacy-preserving security mechanism: it identifies the client software, not the user.

However, the combination of JA4 with IP address and session data could theoretically contribute to user tracking. GDPR and privacy regulations require that CDN operators document their use of TLS fingerprinting in their privacy policies and ensure that fingerprint data is processed only for legitimate security purposes (bot detection, abuse prevention) rather than for advertising or user profiling.

CDN providers typically store JA4 fingerprints in access logs alongside request data. Organizations subject to data retention regulations should include JA4 data in their log retention policies and ensure that log analysis systems treat fingerprint data with the same security controls applied to other client metadata. The fingerprint itself does not constitute personal data under most frameworks, but its combination with other request fields may meet the threshold for personal data classification in some jurisdictions.

Deployment Best Practices

Start JA4 deployment in observation mode. Log JA4 fingerprints alongside User-Agent strings for two to four weeks without taking enforcement actions. This baseline reveals the fingerprint distribution of your legitimate traffic and identifies any unusual but authorized client software. Many organizations discover legitimate internal tools, monitoring systems, and partner integrations during the baseline period that would have been incorrectly blocked by an immediate enforcement deployment.

Build your fingerprint policy from observed legitimate traffic rather than from a blocklist of known bad fingerprints. A allowlist approach — permitting known-good JA4 fingerprints for specific endpoints — is more resilient than a blocklist because new bot tools produce new fingerprints that a blocklist cannot anticipate. For public-facing endpoints, use JA4 mismatches (UA/fingerprint inconsistency) as a primary signal rather than fingerprint matching, since this catches impersonation regardless of which fingerprint the bot presents.

Combine JA4 with DDoS protection, rate limiting, and WAF rules in a layered defense architecture. JA4 excels at identifying what a client is; rate limiting controls how much a client can do; WAF rules inspect what a client sends. No single layer catches everything, but together they create a defense depth that dramatically raises the cost for attackers while keeping false positive rates negligible for legitimate users.