TLS Fingerprinting (JA3, JA4): What It Proves and What It Doesn't

What is a TLS fingerprint?

A TLS fingerprint is a short identity stamp derived from the first message a client sends when it opens a TLS connection. That message is the ClientHello. It lists which options the client software (a browser, curl, a Python library) supports, and each piece of software writes that list in its own preferred order. Summarize the list and you get a stamp specific to the software stack.

The stamp says: "this connection comes from a TLS stack of this family." It does not say "this person made the connection" or "this person is malicious." That gap is the foundation of using fingerprints correctly.

What does a ClientHello contain?

The TLS 1.3 handshake is defined in RFC 8446. The ClientHello is sent unencrypted and carries the fields fingerprints use:

• Protocol version. The TLS version the client offers.
• Cipher suites. The encryption algorithms the client supports, in preference order.
• Extensions. Optional features such as SNI, ALPN, supported groups and signature algorithms.
• Elliptic curves and point formats. The curve groups for key exchange.
• ALPN. The application protocol the client wants to speak, for example h2 or http/1.1.

The server reads these fields without changing them. A passive measurement can extract the fingerprint without slowing the connection.

How does JA3 work?

JA3 is the method Salesforce published. It joins five fields as decimal numbers and takes an MD5 hash: TLS version, cipher suites, extensions, elliptic curves and elliptic curve point formats. Values inside a field are separated by hyphens, fields by commas. The result is a 32-character digest.

JA3's strength is simplicity. Its weakness is order sensitivity. When Chrome began randomizing extension order, one browser version started producing many different JA3 values, which weakened JA3 for browser identification. For stacks that do not randomize (many HTTP libraries and bot tools), JA3 remains stable.

How does JA4 work?

JA4, developed by FoxIO, is a family that aims to fix JA3's limits. A JA4 fingerprint has three parts, JA4_a_b_c:

• a: the readable section. Transport type (TCP or QUIC), TLS version, whether SNI is present, cipher and extension counts, ALPN.
• b: a truncated hash of the sorted cipher suites.
• c: a truncated hash of the sorted extensions and signature algorithms.

Because of the sorting, shuffling extension order does not change the fingerprint. The readable a section adds value for analysts: you see the version and ALPN without looking at a raw hash. That lets you group fingerprints and spot a new stack.

What is an HTTP/2 fingerprint?

A TLS fingerprint measures the handshake. An HTTP/2 fingerprint measures the first settings after the connection is up: the SETTINGS frame values, the WINDOW_UPDATE size, priority frames and header order. The Akamai-style format collects these values into one string. Each browser sends its own values, so this is a second, independent layer next to TLS. If the two disagree (for example, a Chrome-like TLS handshake with HTTP/2 settings that do not look like Chrome), that is a meaningful warning.

What does a fingerprint look like in practice?

A JA4 string looks like this: t13d1516h2_8daaf6152771_b186095e22b6. The first part, t13d1516h2, reads: over TCP (t), TLS 1.3 (13), SNI present (d), 15 cipher suites, 16 extensions, ALPN h2. The next two parts are truncated hashes of sorted lists. The string only illustrates the format; real values vary by client and version.

A useful analyst workflow: count the fingerprints reaching your site, match the most common ones to known browsers, and inspect the rare and new ones. If a fingerprint arrives from hundreds of different IPs and almost never passes verification, it may be a bot tool's signature.

When can a fingerprint mislead?

• TLS-terminating middleboxes. Corporate security proxies re-establish the connection. The fingerprint reaching your server is the proxy's, not the browser's.
• Browser updates. A new version means a new fingerprint; stale lists can flag real users.
• Rare but legitimate clients. Old devices, embedded systems, command-line tools and monitoring services carry unusual fingerprints.
• In-app browsers. Web views inside mobile apps use the system stack and look different from a desktop browser.

What can a fingerprint prove?

Example: a request carries a Mozilla/5.0 ... Chrome/... User-Agent, but the fingerprint belongs to a Python HTTP library. That mismatch is a strong hint. The reverse does not hold: a Chrome fingerprint does not prove the client is not a bot, because a bot driving real Chrome through automation produces the same fingerprint.

Fingerprints are also shared. Hundreds of employees on a corporate network with the same browser version produce the same one. Enforcing on it alone punishes those users.

Why can a fingerprint be spoofed?

TLS impersonation libraries reproduce a real browser's ClientHello and HTTP/2 settings exactly. With one of them, an attacker makes a request look like Chrome. A fingerprint will not stop a determined attacker, but it filters cheap bots: most off-the-shelf tools give themselves away with their default configuration. To catch the advanced attacker you need behavior and challenge layers; see bot protection and CAPTCHA alternatives.

How do you use fingerprints safely?

1. Treat it as one signal. Add the fingerprint to a risk score; do not make it a separate block rule.
2. Start in shadow mode. Record first and add no points. Learn which fingerprints belong to legitimate users on your real traffic.
3. List shared fingerprints. Common fingerprints arriving from many different IPs are browsers; do not block them.
4. Keep the data fresh. Browser versions change, and fingerprints age.
5. Watch false positives. Complaints from blocked legitimate users are the most direct feedback.

Sources

• FoxIO JA4 repository
• Salesforce JA3 repository
• RFC 8446: TLS 1.3

Related product pages:Technology