Peakhour.IO - JA4

What an Open Network Fingerprint Database Should Publish

2026-09-06T09:00:00+10:00

An open fingerprint database should let another researcher disagree with it.

That requires more than a hash and an application name. The row needs to show which bytes produced the fingerprint, how the label was established, where the traffic was observed, which software generated the value and what competing explanations remain plausible.

Most public databases were built for a narrower purpose. Historical JA3 lists made values easy to share. Threat feeds made malware observations easy to match. Nmap and p0f made signature rules executable. TLS observatories count what appears at their vantage points. Those are sensible designs for their jobs.

They do not yet add up to a reusable open ground-truth corpus.

Start with observations, not verdicts

The fundamental database object should be an observation:

{
  "observation_id": "...",
  "observed_at": "2026-07-12T00:00:00Z",
  "capture": {
    "position": "client-facing edge",
    "collector": "mercury",
    "collector_revision": "3172786...",
    "source": "controlled-client-run"
  },
  "fingerprints": [],
  "labels": [],
  "evidence": [],
  "licence": "..."
}

The observation can then carry several fingerprint methods and several candidate labels. This is safer than making the hash the primary truth and forcing one application name into the same row.

Store the reversible material

Each fingerprint entry should contain the published identifier and the material used to derive it:

{
  "method": "ja4",
  "implementation": "FoxIO Python",
  "implementation_revision": "...",
  "value": "t12d2709h2_..._...",
  "raw_value": "t12d2709h2_002f,...",
  "source_message_digest": "sha256:...",
  "truncated": false
}

For JA3, retain the five-part source string beside the MD5. For JA4, retain JA4_r where collection policy permits it. For Mercury, retain the complete versioned NPF string rather than only its hash nickname. For HASSH, retain the algorithm lists. For a matcher rule, retain the response bytes or sanitised fixture that satisfied it.

This permits field-level comparison, implementation testing and migration when a definition changes. It also exposes incompatible values hidden behind a common field name.

Make labels many-to-many

Labels should be separate evidence-backed assertions:

{
  "type": "process",
  "value": "example-client",
  "version": "1.2.3",
  "source": "endpoint-telemetry-join",
  "review_state": "reviewed",
  "confidence": 0.94,
  "first_seen": "...",
  "last_seen": "..."
}

One fingerprint can have several process labels because applications share libraries. One process can have several fingerprints because versions, platforms and configurations differ. The schema should preserve counts and conflict instead of selecting one winner during ingestion.

Cisco Mercury's public resource schema points in this direction: fingerprint entries contain candidate processes, observation counts, operating systems and destinations. The production database is private, but the many-to-many model is the right starting point.

Describe how ground truth was produced

Use a controlled vocabulary for evidence sources:

controlled_capture
endpoint_process_join
malware_sandbox
reviewed_pcap
active_probe_match
passive_observation
community_submission
derived_from_external_database

Each type needs its own metadata. An endpoint join should record the join window and ambiguity rules. A controlled capture should name the client build, operating system and generation script. A malware sandbox label should identify the sample and distinguish the sandbox process from the malware process. A community submission should identify what a reviewer actually checked.

Derived labels should never masquerade as independent evidence. If a mapping was imported from an older JA3 list, cite that row and keep its original uncertainty.

Separate prevalence from classification

Prevalence belongs in observation aggregates:

{
  "source": "university-vantage-a",
  "first_seen": "...",
  "last_seen": "...",
  "count": 184233
}

It should not silently increase application-label confidence. A common fingerprint is not necessarily well-labelled; a rare fingerprint is not necessarily suspicious.

The TLS Fingerprint Observatory demonstrates the value of publishing counts even when labels are missing. Its large unlabelled TLS corpus is more useful for prevalence research than a catalogue filled with guesses.

Represent threat observations explicitly

A malware feed should attach an observation, not overwrite the fingerprint's identity:

{
  "type": "malware-sandbox-observation",
  "family": "example-family",
  "sample_sha256": "...",
  "observed_at": "...",
  "known_good_evaluation": "not-performed"
}

This retains the warning published by sources such as SSLBL. It allows a consumer to ask whether a fingerprint was seen in malware without treating every matching benign process as infected.

Publish validation sets and negative evidence

A useful database should include:

controlled positive captures;
known-good observations that share supposedly malicious fingerprints;
deliberately conflicting labels;
client upgrades that changed fingerprints;
malformed and truncated handshakes;
captures before and after a TLS-terminating proxy;
implementation conformance cases.

Negative and conflicting evidence is not database dirt. It tells consumers where a label stops working.

Version the data and the interpretation

Every release should state:

schema version;
database snapshot identifier;
fingerprint implementation revisions;
collection time range;
label additions, removals and merges;
retired mappings;
licence changes;
reproducible validation results.

Consumers should be able to pin a snapshot and explain which database caused a decision. A live service may remain convenient, but an incident review needs the state that existed when the event was classified.

Make licensing part of the schema

Fingerprint method, implementation and dataset rights are separate.

Core JA4 is BSD-licensed. Other JA4+ methods use different FoxIO terms. Nmap's data files use the Nmap Public Source License. A combined historical repository may contain rows imported under different licences. An API may permit lookup but prohibit bulk redistribution.

Store a licence or source-rights reference for each imported dataset and, where necessary, each record. If the rights are unclear, publish a pointer and transformation recipe rather than republishing the row.

Provide a confidence model that can be audited

A score without calibration is decoration. For each label type, document:

what the score estimates;
the labelled validation set;
true-positive and false-positive definitions;
treatment of unseen applications;
time and environment holdouts;
how conflicts and stale observations affect the score.

Where calibration is unavailable, use review states such as submitted, reproduced, reviewed and contested instead of inventing numeric precision.

The minimum viable open record

If full packet evidence cannot be published, a useful minimum is:

method and rule version
implementation revision
compact and raw fingerprint
candidate label, including version/platform
ground-truth method
capture position
first and last seen
observation count
confidence or review state
evidence reference
licence

That is more expensive than a CSV containing hash,name. It is also what makes the mapping useful outside the environment and assumptions of its original collector.

The public ecosystem already contains most of the parts: JA4DB's cross-method model, the TLS observatory's prevalence data, Mercury's candidate-process and destination schema, FingerprinTLS's retained ClientHello fields, and executable fixtures in matcher projects such as Rapid7 Recog. The missing step is to combine those strengths without erasing provenance.

For the current resource landscape, see Public Network Fingerprint Databases and What They Cover. For the import checklist, see How to Evaluate a Network Fingerprint Database.

Public Fingerprint Databases Are Not Ground Truth

2026-08-30T09:00:00+10:00

Network fingerprint formats are public. Reliable labels are not.

We reviewed the main public JA3, JA4, TLS, TCP, HTTP, SSH, JARM, DHCP, operating-system and service-fingerprint resources. The result was not one large ecosystem of interchangeable databases. It was a set of much narrower things: small mapping samples, old signature lists, active-probe rules, malware feeds, account services and a large observatory whose TLS records are almost entirely unlabelled.

That is not a criticism of the maintainers. It is a warning about what happens after a fingerprint field reaches a dashboard. A precise-looking value invites a precise-looking name. The evidence behind that name may be a controlled capture, a best guess from 2018, a community submission or a malware sandbox observation that was never compared with benign traffic.

Those labels should not produce the same decision.

The largest public TLS database has almost no TLS labels

The relaunched TLS Fingerprint Observatory is an unusually valuable public resource. It exposes more than a million distinct TLS fingerprints and billions of passive observations from the University of Colorado Boulder and Merit Network. Records can include first and last seen, counts by source, cipher suites, extensions, groups, signature algorithms, ALPN and other parsed fields.

At the time of our review, essentially none of the TLS fingerprints had implementation labels.

That fact makes the observatory more credible, not less. The collection can answer prevalence and protocol-evolution questions without pretending it knows which application created every handshake. Its smaller QUIC corpus has several hundred controlled labels, often tied to generated capture files.

The limitation is equally clear. A prevalence database cannot become a browser or malware classifier merely because its records are detailed. The labels require another source of truth.

The public JA4 database is a sample, not JA4DB

FoxIO maintains JA4DB, a hosted service covering several JA4-family methods, applications and detection guidance. It is the closest current service to a multi-surface mapping database.

The public file most people can inspect is different. FoxIO's ja4plus-mapping.csv contains 66 data rows. Only 35 carry a core JA4 value; the other JA4+ columns are sparser.

That file is useful documentation. It shows how an application, library, device, operating system and several network observations can sit in one row. It is not broad enough to serve as a general browser, bot or malware catalogue.

The hosted service is now account-oriented. Its bulk-data licence and per-record provenance are not publicly clear enough to call it an open database. Core JA4's BSD licence does not automatically cover the hosted labels, and it does not cover all other JA4+ methods under the same terms.

The open JA3 mappings are mostly historical

Salesforce's archived JA3 lists contain roughly 159 application mappings for macOS and Linux. The repository describes them as example or best-guess material. They have no per-row capture date, client version, source PCAP or confidence.

Trisul's ja3prints is larger: 626 JSONL mappings assembled from Salesforce examples, malware-traffic-analysis captures, FingerprinTLS and browser additions. Its last update was in 2018, and the combined dataset does not have a clear repository-wide licence.

The historical FingerprinTLS database preserves richer ClientHello fields than JA3, which makes it valuable for research. It is now archived, and many records lack consistent capture dates, operating-system evidence and confidence.

These sources still matter. They document the lineage and can help with an older incident. They should not silently become current application ground truth.

Rules are not observations

Some of the strongest public databases are actually matcher corpora.

Nmap's OS database contains actively maintained probe-response signatures. Nmap service probes combine test payloads with regular expressions that extract products and versions. Rapid7 Recog maintains XML signatures for SSH, HTTP, SNMP, favicons, JARM and other surfaces. p0f's p0f.fp contains passive TCP and HTTP traits, although its upstream corpus is now dated.

These resources can be excellent at their stated job. A rule match means that a response satisfied the signature. It does not establish population prevalence, exclusivity or a particular process behind the connection.

Flattening a matcher result into the same table as an observed application mapping discards that distinction.

Malware observation is not malware identity

SSLBL publishes a JA3 blacklist under CC0. It records fingerprints observed while analysing more than 25 million malware PCAPs and offers both CSV and Suricata rules.

SSLBL also says the values were not tested against known-good traffic and may cause substantial false positives.

That warning is part of the data. A row supports this statement:

malware samples assigned this family label produced this JA3

It does not support this statement:

every connection with this JA3 is that malware

Shared libraries make the second statement unsafe. Cisco's destination-context research examined public malware JA3 indicators and found that many were more strongly associated with benign processes in its enterprise observations.

VirusTotal's behavioural pivots have the same boundary. Files sharing a JA4 may be related malware, come from one developer or merely use the same TLS library. The pivot begins an investigation; it does not finish one.

Mercury publishes the schema, not the labels

Cisco Mercury offers one of the clearest public designs for a fingerprint knowledge base. Its resource documentation describes mappings from fingerprints to candidate processes, process counts, operating-system observations and destinations. The classifier can use destination address, port and server name to rank those candidates.

The current Cisco-labelled resource database is not in the public repository.

This is an honest architectural boundary. The NPF format, collector and database contract are inspectable. The production labels depend on continuously collected endpoint, network and malware-analysis data that Cisco does not publish as an open corpus.

What is actually missing

The public ecosystem does not mainly need another hash list. It needs evidence attached to each mapping:

the raw or reversible fingerprint;
the method and implementation version;
an independent label source;
capture position and environment;
first and last seen;
observation count;
competing labels;
confidence and review state;
a usable dataset licence.

Almost none of the public resources supplies all of these. Some optimise for scale, some for current labels, some for inspectability and some for rules that can run in an existing scanner.

The practical response is to preserve those categories. Use an observatory for prevalence, a matcher corpus for response signatures, a threat feed for malware observations, and a mapping database for candidate labels. Then validate the result against local evidence before it reaches enforcement.

The full directory is in Public Network Fingerprint Databases and What They Cover. The evaluation checklist is in How to Evaluate a Network Fingerprint Database.

Using Network Fingerprints in Bot and Rate-Limit Decisions

2026-08-23T09:00:00+10:00

A network fingerprint is a useful rate-limit key. It is a poor verdict.

That sounds like a small distinction, but it changes how a control behaves. A limit keyed only by source IP can miss a distributed scraper moving through thousands of addresses. Add a TLS or HTTP fingerprint and the requests may fall into a recognisable cohort. The operator can count and compare them even while the IPs rotate.

The same key can also group thousands of ordinary users running the same browser release. If the control reads “this fingerprint is a bot” and blocks it everywhere, the grouping feature has become a false-positive multiplier.

The practical job is to use the fingerprint where grouping helps, then make the decision from the route, behaviour and consequence. This article sets out one way to do that.

Start with the route, not the fingerprint

A request for a cached image and a request to submit a password do not deserve the same policy. Neither do a search request and an export that starts an expensive database job.

Before adding fingerprint data, classify the routes that matter:

what the request can change or disclose;
whether it consumes scarce application or origin capacity;
whether a legitimate user can retry safely;
whether the client can complete a challenge;
which identity is available, such as an account, session, API key or no identity at all;
what an incorrect block would cost.

This route map sets the response. An unfamiliar cohort fetching public content might only be worth observing. The same cohort attempting passwords across many accounts may justify a tight shared limit. A fingerprint mismatch on an authenticated payment action may call for step-up verification rather than a network block.

Route sensitivity also prevents a common emergency mistake: applying a site-wide rule because an attack was visible on one endpoint. Narrow rules are easier to explain, test and remove.

Use the fingerprint as a cohort key

JA3, JA4 and Cisco Mercury do not identify a person or device. Each method selects and normalises protocol fields, then groups connections that look equivalent under those rules. Our same-ClientHello lab shows how three methods produce three different representations from one handshake.

That makes the fingerprint useful for questions such as:

Are login failures arriving from many IP addresses but one narrow set of client stacks?
Did an expensive API route suddenly attract a new protocol cohort?
Does traffic claiming to be a browser have a consistent TLS, HTTP and header shape?
Did a cohort disappear after an abusive tool changed version, or did the fingerprinting rules change underneath us?

The key should be composite. A workable rate counter might resemble:

route_class + fingerprint_method + fingerprint_version + fingerprint_value

Depending on the abuse case, add an account, tenant, API credential, ASN or country. Do not throw every field into every key. An over-specific key divides a distributed campaign into buckets too small to see; an over-broad key combines unrelated users.

Run a few candidate keys in observation mode and measure their bucket sizes. Look at both tails. A key that places half the site's users in one bucket is too blunt for direct enforcement, however suspicious that bucket looked during one incident.

Record where the value came from

Fingerprint provenance is operational data, not documentation trivia.

At an origin behind a CDN or reverse proxy, the visible TLS connection may belong to that intermediary. A fingerprint forwarded in a header might describe the original client-facing connection, or it might describe a later hop. The receiving service cannot tell from the hash alone.

For each event, keep at least:

method:       ja4
version:      pinned implementation or rule version
value:        t13d..._..._...
capture:      client-facing edge
source:       named collector or trusted forwarding hop
observed_at:  timestamp
policy:       policy identifier and revision
action:       observe, challenge, rate-limit or block

Where the format permits it, retaining the selected raw fields or unhashed representation makes later comparison much easier. Cisco Mercury's full Network Protocol Fingerprint is structured and versioned; its optional hash is a compact nickname that discards that structure. JA4 publishes both a canonical hashed form and a raw JA4_r form. The details are in the Mercury NPF specification and JA4 technical specification.

Trust the forwarding path as deliberately as any other security metadata. Strip client-supplied copies at the boundary, set the authoritative value there, and record the hop that produced it. Otherwise an attacker may be able to choose the value used by the policy.

Use an action ladder

Bot controls work better with space between “allow” and “block”. A simple ladder is observe, challenge, rate limit, then block. It is not a mandatory sequence for every request; it is a way to match disruption to confidence.

Observe

Observation is the right first action for a new cohort, a changed implementation or a weak hypothesis. Record volume, routes, account outcomes, response codes, request cost and how the cohort overlaps with known legitimate clients.

Set an end date before starting. “Log this for seven days and review on Monday” produces a decision. “Log this” often produces another permanent stream nobody owns.

Challenge

A challenge asks the client for more evidence. It can separate some interactive browsers from simple automation, but it is not a universal test of humanity. Browser automation can complete challenges; privacy software, accessibility tools and broken JavaScript can make legitimate users fail them.

Use challenges where the client can reasonably complete one and where failure has a safe recovery path. They are a poor fit for machine-to-machine APIs unless the protocol already defines an authentication or proof step.

Rate limit

Rate limiting fits repeated or costly behaviour. Count a cohort against the route it is affecting, then layer in the identities that make sense for that route. For example:

login:  fingerprint + account + failed outcome
search: fingerprint + route + request cost
API:    fingerprint + tenant or credential + operation

A limit should say what it protects. Requests per minute is sometimes enough. Expensive operations may need a cost-weighted budget. Login protection may count failed attempts while allowing successful account recovery to proceed. Distributed abuse may need a cohort-wide ceiling plus per-account and per-IP limits so that no single key carries the whole policy.

Return an explicit response and keep the retry behaviour predictable. The HTTP 429 Too Many Requests status was defined for rate limiting in RFC 6585, including the option to send Retry-After. Clients still need sensible backoff, and operators need to watch whether retries are making origin pressure worse.

Block

Block when the evidence is strong, the harm is current, and a less disruptive action cannot protect the route. Good candidates include a confirmed exploit tool hitting the vulnerable route, a cohort causing active availability loss, or repeated abuse that has failed narrower controls.

Keep the scope bounded: fingerprint method and version, affected route, relevant behaviour, start time, owner and expiry. A bare fingerprint deny-list with no incident context is hard to audit and tends to outlive its evidence.

For a broader mapping of actions to evidence, see Network Fingerprint Signals and Security Decisions and Network Fingerprinting for Rate Limiting.

Combine evidence before increasing friction

The most useful policy does not ask whether a fingerprint is good or bad. It asks whether several observations agree.

Consider a login campaign. The source addresses rotate through residential networks. The TLS cohort is common because the tool drives a real browser. The fingerprint alone is weak. But the same traffic may attempt many accounts, reuse a route sequence, fail at a high rate, omit normal session history and arrive at a cadence unlike ordinary users. Together those observations justify a shared limit or challenge.

Now reverse the example. A rare TLS cohort signs in successfully to one account from its usual region, follows a normal route sequence and maintains an established session. Rarity does not add much. Blocking it would mostly punish an unusual client.

This is also the line between a format and a detection system. JA4 defines a fingerprint. Mercury defines fingerprint representations and includes separate analysis components. Any claim such as “this is Chrome”, “this is a scraper” or “this is malicious” comes from surrounding data and inference, not from the fingerprint characters themselves. A Network Fingerprint Is a Cohort, Not a Client explains that boundary in more detail. Fingerprints Are Evidence, Not Identity covers the same problem across browser, network and behavioural fingerprints.

Expect versions and populations to drift

Browsers ship, TLS libraries change defaults, mobile applications update unevenly and attack tools copy popular handshakes. Fingerprint implementations also change their parsing rules. Store the method and implementation version so client drift can be separated from detector drift.

Before changing an implementation, calculate old and new values side by side on a sample. Compare cohort sizes and known-good traffic by route. A partner API, mobile application and public website have different expected populations; a global label may be irrelevant to the local control.

Put expiry and rollback in the policy

Every enforcement rule needs an owner, reason, expiry and removal condition. Before enabling it, record request volume, successful transactions, challenges, 429 responses and origin health. Compare the same measures afterwards. A falling attack rate is not success if legitimate completion falls with it.

When a false positive appears, retain the fingerprint version, capture point, contributing evidence, route, identity, policy revision and rollback result. That record shows whether to change a threshold, split a route class, add an exception, demote the action or remove the fingerprint from the key.

A deployable first policy

For a first production use, choose one abused route. Generate a versioned fingerprint at a trusted capture point, log it beside the route and outcome, and observe cohort sizes long enough to include normal variation. Then choose one reversible action with success measures, rollback and an expiry.

The fingerprint has done its job when it helps a team see and control a group of requests that an IP-only rule would miss. It has exceeded its job when the group is treated as proof of a client, person or intent.

Does TLS Fingerprint Canonicalisation Hide Attacker Variation? How to Test It

2026-08-16T09:00:00+10:00

Canonicalisation solves a real problem in TLS fingerprinting. If two ClientHello messages differ only because a client shuffled its extensions, treating them as unrelated fingerprints creates noise. Sorting those extensions puts the messages back into one cohort.

It also destroys the original order.

That is not automatically a mistake. A fingerprint is useful partly because it ignores variation that does not help with the job at hand. The unanswered question is whether some of the discarded variation separates ordinary client behaviour from automation, scanners or deliberate evasion.

Our one-ClientHello lab cannot answer that. It proves that three pinned implementations produce recorded representations from the same bytes. It says nothing about a population of clients or attackers. Answering the canonicalisation question needs a corpus and a labelled experiment.

What gets collapsed?

JA3 removes GREASE values but otherwise preserves the order of the selected cipher, extension, supported-group and point-format lists. Change one of those ordered inputs and the MD5 digest changes.

JA4 deliberately defines a broader equivalence class. Its canonical b section hashes sorted cipher identifiers. Its c section hashes sorted extension identifiers followed by signature algorithms in their advertised order. SNI and ALPN extension codes are omitted from that list because related information is represented in the readable a section. FoxIO's JA4 specification documents those choices.

Cisco Mercury makes the rule version visible. In the current draft NPF specification, the older unversioned TLS format retains extension order, tls/1 sorts all represented extensions, and tls/2 sorts selected extensions while applying more specific inclusion and normalisation rules.

These methods do not merely encode the same fingerprint differently. They define different ideas of “the same”.

Why Chrome forced the issue

Chrome's extension permutation rollout showed why order-sensitive identifiers can become operationally brittle. Peakhour's 2023 analysis recorded a sharp rise in unique order-sensitive signatures after the change. The browser family had not suddenly split into thousands of independent TLS implementations. Much of the new variation came from ordering.

Sorting is an effective response if the goal is to recover the implementation cohort. It is also consistent with Chrome's stated reason for making the change: servers and middleboxes should not depend on one fixed extension order.

But an analyst may have another question. Does a tool permute extensions using the same mechanism and constraints as the browser it imitates? Does a scanner generate an ordering distribution that differs from Chrome's? Does malware preserve the static order supplied by its TLS library while claiming a Chrome user agent?

A canonical JA4 can group those handshakes even when their ordering behaviour differs. That is expected. JA4 answered the cohort question, not every possible behavioural question.

The wrong experiment

Counting how many unique raw fingerprints map to one canonical fingerprint is a useful descriptive statistic. It is not, by itself, evidence that canonicalisation weakened detection.

A common browser with extension permutation should produce many raw orders. A large raw-to-canonical ratio may therefore be evidence of normal deployment scale. Calling every collapsed value a loss of “fidelity” assumes that all variation was useful before the test has measured its relationship with any outcome.

The reverse shortcut is also wrong. Stable canonical values do not prove that sorting is harmless for every detector. A field can be poor for application identification but useful for distinguishing one implementation path, library version or evasion technique.

The experiment needs labels and a defined decision.

A testable study design

We would structure the study around observations, transformations and outcomes.

1. Preserve the original ClientHello

Store the permitted raw handshake metadata or a reversible representation alongside derived identifiers. Record:

capture point and TLS termination path;
sensor implementation and revision;
timestamp and software-release period;
JA3 source string and digest;
JA4, JA4_r, JA4_o and JA4_ro where the implementation provides them;
a full, versioned Mercury NPF string;
HTTP and browser claims kept separate from the TLS representation.

Without the raw or reversible material, a later study cannot recover the ordering that canonicalisation removed.

2. Define labels that do not come from the fingerprint

Labels need an independent source. Depending on the environment, that could include controlled browser runs, endpoint process telemetry, sandbox execution, signed test clients or reviewed incident cases.

Do not label traffic as Chrome because its JA4 resembles Chrome and then report that JA4 identifies Chrome. That is circular evaluation.

Cisco's destination-context research used joined endpoint and network observations to build process labels. The paper also discusses how sandbox and environment choices affect the resulting knowledge base. Accurate TLS Fingerprinting Using Destination Context and Knowledge Bases is useful here because it treats ground truth as a system component rather than a list of famous hashes.

3. Compare representations at the same grouping level

Measure at least:

raw ordered representation;
canonical JA4;
useful JA4 component combinations such as JA4_ac;
Mercury rule versions that preserve or sort different structures;
raw ordering features added beside the canonical value.

The comparison should use the same captures, time split and labels. Otherwise a newer fingerprint method can appear better simply because it was evaluated on newer or cleaner data.

4. Use time and environment holdouts

Randomly splitting individual connections leaks near-duplicates between training and test data. Prefer a forward time split and, where possible, a separate network or capture environment.

That exposes two operational questions: does the result survive a browser or library update, and does it survive outside the environment where the labels were collected?

5. Measure decisions, not just uniqueness

Useful measurements include:

collision and fragmentation rates by independently labelled client;
precision and recall for a stated classification or detection task;
false-positive rates on high-volume legitimate cohorts;
stability across software releases;
the incremental value of raw order after canonical identifiers and context are already present;
review volume at an actual alert or policy threshold.

If adding original order improves a classifier by a tiny amount but creates millions of unstable keys, the operational cost may outweigh the gain. If it separates a specific impersonation technique with few false positives, keeping it as a secondary feature may be worthwhile.

Keep both when the questions differ

The design choice does not have to be raw or canonical.

A compact canonical identifier is useful for grouping, counters, joins and rules. A raw or reversible representation is useful for investigation, feature research and migration when the canonical rules change. Storage policy can keep the compact value broadly and retain detailed material for a bounded sample, selected security events or an approved research window.

That split also makes detector claims easier to audit. The rule can say it grouped on JA4 while the event retains enough source material to explain which handshake produced the value.

What we can say now

Sorting removes ordering information. It reduces fragmentation caused by clients that permute their lists. Both statements follow from the format definitions and can be demonstrated with controlled captures.

Whether the removed order contains useful attacker variation is an empirical question tied to a dataset, capture point, label source and decision. Until that study is run, the honest position is to preserve the evidence needed to test it and avoid turning either uniqueness or stability into a claim of detection accuracy.

For the wider format comparison, see Mercury vs JA4 vs JA3. For the identity boundary that applies to every result, read A network fingerprint is a cohort, not a client.

A Network Fingerprint Is a Cohort, Not a Client

2026-08-09T09:00:00+10:00

A TLS fingerprint usually tells you that two connections look alike under a particular set of rules. That is useful. It is not the same as showing that they came from the same client.

The distinction becomes obvious when a common TLS library sits underneath many programs. Those programs can offer the same protocol version, cipher suites, extensions and signature algorithms. A fingerprint built from those fields groups them together even though their purpose, owner and risk are different.

The reverse also happens. One application can generate several fingerprints after a browser update, operating-system change, feature rollout or configuration difference. A fixed application name does not imply a fixed ClientHello.

The safest mental model is a cohort: traffic that looks the same after a fingerprint method has selected and normalised its inputs.

The method defines the cohort

JA3 preserves the order of its selected ClientHello feature lists. Change the order and the MD5 value changes. JA4 sorts selected identifiers before calculating two of its components, so permutations that split a JA3 cohort may remain grouped under JA4.

Cisco Mercury can preserve more packet-derived structure in its full Network Protocol Fingerprint. Different Mercury rule versions also make different normalisation choices. A tls/2 value is therefore not just a longer spelling of JA4. It is the result of another feature-selection contract.

This means there is no format-independent "real fingerprint" hiding underneath the tools. Each method answers its own equivalence question: which differences count, and which should be ignored?

Our same-PCAP lab demonstrates that point without relying on a hypothetical browser. The three tools inspect the same ClientHello and produce representations with different retained detail.

Common does not mean safe

A popular browser fingerprint will naturally appear in a great deal of legitimate traffic. An attacker can also use a browser, drive one through automation, or imitate its TLS stack. Matching a common browser value therefore says little about intent by itself.

The opposite shortcut is just as risky. An uncommon fingerprint is not proof of malware. Internal tools, older mobile applications, embedded devices, accessibility software and regional client variants can all be rare in one dataset.

Rarity is relative to the observation point. A fingerprint that is common across a public content site may be unusual on an administrative API. A value common in one country, network or month may be rare in another.

Capture point changes what you see

TLS fingerprinting only works where the relevant handshake is visible. At an origin behind a CDN or reverse proxy, the TLS connection may have been terminated and replaced upstream. The origin can then observe the proxy's connection rather than the end user's ClientHello unless the edge explicitly forwards a derived fingerprint.

That forwarded value also needs provenance. Operators should know which implementation and format version produced it, whether it came from the client-facing connection, and whether middleware transformed or sampled the traffic.

Without that information, two values that look compatible may have been generated under different rules. Fastly has documented how implementation differences can undermine the portability promised by a shared hash in The State of TLS Fingerprinting.

Context can improve an inference

Cisco's Mercury research is helpful because it does not hide the ambiguity. The 2020 destination-context paper reports that one TLS fingerprint often maps to tens or hundreds of process names. Its classifier adds destination IP address, port and server name, backed by a labelled knowledge base, to rank the possible processes.

That is stronger than treating a bare fingerprint as an application name. It is still conditional. Change the environment, the age of the knowledge base, the available destination fields or the software population and the probabilities can change. The paper's reported accuracy belongs to its datasets and experimental design, not to every network that runs Mercury.

JA4 deployments often add context too. A security platform might combine the JA4 value with request rate, geography, path, account state or observations from other customers. Those extra fields are not secretly part of JA4. They are features in the surrounding detection system.

Use fingerprints where grouping helps

Fingerprints earn their place when grouping similar connections improves an investigation or control. Examples include:

counting login failures across rotating IP addresses;
finding a TLS stack that appeared at the start of an incident;
comparing a claimed browser with HTTP and browser-side evidence;
monitoring drift after a client or library release;
selecting traffic for review before writing a narrower rule.

For the decision and enforcement consequences, see Fingerprints are evidence, not identity. The protocol-specific conclusion here is narrower: a matching TLS fingerprint places connections in a cohort defined by one method. It cannot tell you, on its own, who is on the other end.

The practitioner follow-up, Using network fingerprints in bot and rate-limit decisions, turns that boundary into a route-scoped policy and rollback model.

Two Lineages of TLS Fingerprinting: JA3, JA4 and Cisco Mercury

2026-07-26T09:00:00+10:00

It is tempting to draw the history of TLS fingerprinting as a single line: JA3, then JA4, with Cisco Mercury somewhere nearby. That version is tidy. It is also wrong.

Two strands of work developed around the same observation: a TLS ClientHello exposes enough information to say something useful about the software that created it. One strand concentrated on portable identifiers that could be logged and exchanged. The other concentrated on retaining protocol structure and combining it with evidence that could improve classification.

JA3 and JA4 belong mainly to the first strand. Cisco Mercury belongs mainly to the second. For the technical work that preceded JA3, see how TLS handshakes became fingerprints.

Before JA3

Passive fingerprinting predates TLS. Tools such as p0f identified operating-system characteristics from TCP/IP behaviour without sending probes to the target. Researchers later applied the same instinct to fields exposed during SSL and TLS negotiation.

In 2009, Ivan Ristić published an SSL handshake fingerprinting experiment that compared ClientHello messages from web clients. Marek Majkowski followed with a TLS fingerprinting patch for p0f in 2012. Lee Brotherston's FingerprinTLS later provided tools and a database for creating and matching TLS fingerprints.

Salesforce's JA3 project drew directly on that work. JA3 serialised five ordered ClientHello feature groups, removed GREASE values and calculated an MD5 digest. The result was compact enough to put in a log, share in threat intelligence or match in a rule. The archived JA3 repository documents both the format and its debt to FingerprinTLS.

JA3's compactness came with a cost. A digest does not explain why two clients differ. Ordered inputs also meant that harmless permutation could produce a different value. Most importantly, a matching digest did not prove that the traffic came from one application. Programs built on a shared TLS library could produce the same ClientHello.

The JA4 branch

FoxIO introduced JA4 in 2023 after Chrome began permuting TLS extension order. Peakhour saw the practical effect of that change in our Chrome extension-randomisation analysis: a representation that preserved extension order split one common browser family into a large number of values.

JA4 canonicalises selected ClientHello features before hashing them. Its a_b_c structure keeps a readable summary in the first section, a digest of sorted cipher identifiers in the second, and a digest derived from extensions and signature algorithms in the third. This makes the components useful independently. An analyst can group on part of a JA4 value without pretending every field is identical.

That is deliberate lossy compression. JA4 is useful because it throws away distinctions its designers judged unstable or unhelpful for this job. It is not a reversible rendering of the ClientHello, and its truncated SHA-256 sections do not provide a measure of semantic distance. The exact format is set out in the FoxIO JA4 technical specification.

JA4 is one method. JA4+ is the name used for a wider family that includes server, HTTP, TCP, SSH, certificate and other fingerprints. Those methods do not all share JA4's licence, which matters if the fingerprints will be built into a commercial service.

The Cisco research branch

Cisco's work took a different route. In 2016, Blake Anderson, Subharthi Paul and David McGrew studied how observable TLS features could help distinguish malware from enterprise traffic without decrypting it. Their paper, Deciphering Malware's Use of TLS, also dealt with an awkward issue that still matters: malware-sandbox data can bias a classifier.

Anderson and McGrew's 2017 operating-system fingerprinting research combined evidence from TCP/IP, TLS and HTTP across multiple sessions. The point was not to mint a universally portable hash. It was to ask whether several kinds of passive evidence, accumulated over time, reduced uncertainty about the endpoint.

The same multi-protocol approach appears in Cisco's Joy and Mercury projects. Mercury's Network Protocol Fingerprinting format represents selected protocol features as a tree of hexadecimal byte strings. The full form retains structure. Its naming can state the protocol and fingerprint rule version. An optional compact hash can be used where a fixed-length value is more practical. Cisco's current draft NPF specification defines fingerprints for TLS, QUIC, TCP, HTTP, SSH and other protocols.

Mercury also keeps fingerprint generation separate from process classification. That distinction is easy to miss.

A fingerprint and a label are different things

In Cisco's 2020 paper, Accurate TLS Fingerprinting Using Destination Context and Knowledge Bases, the authors found that common TLS fingerprints mapped to many processes. For the 100 most prevalent fingerprints in their May 2020 data, the median was 24.5 process names per fingerprint.

Their response was not a longer hash. They combined the fingerprint with destination address, port and server name, then used a weighted naïve Bayes classifier backed by a continually updated knowledge base.

That produces an inference, not a property embedded in the fingerprint string. The result depends on labelled observations, their age, the monitored environment and the destination evidence available for the connection. The open Mercury repository can generate fingerprints without possessing Cisco's production knowledge base.

This is the clearest difference between the two lineages:

JA3 and JA4 define portable representations for selected TLS observations.
Mercury NPF retains a richer, versioned representation that can be fed into a separate analysis system.
Mercury's destination-context classifier is another layer again.

None of these layers proves who made a request.

Where the lineages meet

The projects respond to many of the same protocol changes. Both JA4 and recent Mercury formats sort selected TLS fields to reduce instability caused by permutation. Both deal explicitly with GREASE. Both recognise that operators need compact values for logs as well as enough detail to investigate differences.

They make different trade-offs. JA4 is convenient for grouping and interchange. Mercury's full NPF form is better suited to inspection and to analysis that benefits from retained structure. JA4's wider family adds fingerprints for other observations, while Mercury is also a packet metadata collector and protocol-analysis library. Comparing only the length of their hashes misses most of the design.

The lab article makes that concrete. In one ClientHello, three fingerprints, we run JA3, JA4 and Mercury against the same packet capture, record the exact tool versions and compare what each output preserves.

One ClientHello, Three Fingerprints: JA3, JA4 and Mercury

2026-07-12T09:00:00+10:00

The easiest way to misunderstand network fingerprints is to compare example strings taken from different clients. We wanted a cleaner test: one packet capture, one TLS ClientHello and three fingerprint formats.

The complete lab is checked into this site's source under labs/network-fingerprinting/, and the publication bundle is available here. It pins the tool revisions, reconstructs the fixture, verifies its checksum, runs the tools and checks that their outputs refer to the same connection. Nothing in the comparison depends on a vendor database or an application label.

The input

The fixture is a 329-byte Peakhour-generated capture containing a local OpenSSL 3.5.6 ClientHello wrapped in one synthetic Ethernet/IPv4/TCP packet:

10.1.1.1:40000 -> 10.2.2.2:443
SNI: lab.peakhour.test

The lab stores the small fixture as base64 under an adjacent BSD 3-Clause licence and verifies the decoded PCAP with SHA-256 before using it. The reserved SNI and private addresses did not cross a network. We select packet 1 and TCP stream 0. That selection matters: saying that several tools read the same PCAP is weaker than proving that their output describes the same flow and ClientHello.

The pinned revisions for this run are:

Cisco Mercury  3172786645f70e1a8347d8cf020b736e185651e5
FoxIO JA4      0e54bc8371de34df94a35f2442c05bda2e8b2034
Salesforce JA3 502cc6395811c54743b0561419d61900a6df3ff7

These pins are part of the result. Fingerprint implementations and specifications change. A value without its method and version is harder to reproduce than it first appears.

Running the lab

From the repository root:

./labs/network-fingerprinting/run.sh
python labs/network-fingerprinting/verify.py

The runner fetches the pinned source archives, builds or invokes the implementations in a temporary work directory, and writes evidence to labs/network-fingerprinting/results/. The verifier checks the fixture and output checksums, connection tuple, SNI and output shape. The pinned source URLs are enforced by the runner rather than inferred by the verifier.

This is a fingerprint-format lab, not a speed test. Build time, runtime and memory use depend heavily on language, wrapper and capture path, so we do not compare them here.

JA3: a portable exact-match digest

For this ClientHello, the canonical JA3 feature string is:

771,49196-49200-159-52393-52392-52394-49195-49199-158-49188-49192-107-49187-49191-103-49162-49172-57-49161-49171-51-157-156-61-60-53-47,65281-0-11-10-35-16-22-23-13,29-23-30-24-25,0-1-2

Its MD5 digest is:

e1934f32e97b0bd52227953ca7d30118

The digest is convenient for logs and exact lookup. On its own it does not show which cipher, extension or group changed. The pre-hash string retains enough information to investigate that difference, which is why throwing it away too early can make later analysis harder.

JA3 removes GREASE values but otherwise retains the order of its selected lists. A client that permutes extension order can therefore generate a new JA3 digest without changing its effective TLS capabilities. The archived Salesforce JA3 repository defines the input fields and GREASE handling.

JA4: canonicalised components

The same ClientHello produces this JA4:

t12d2709h2_a2460661a67a_36cef8aed422

Its first section is readable:

t means TLS over TCP;
12 is the highest supported TLS version after ignoring GREASE;
d says a domain was present in SNI;
27 and 09 are the cipher and extension counts after the format's exclusions;
h2 summarises the first ALPN value.

The second section is the first 12 hexadecimal characters of SHA-256 over sorted cipher identifiers. The third is a truncated SHA-256 value derived from sorted extension identifiers and the signature algorithms in their original order. The canonical JA4 technical specification defines the exact exclusions and encodings.

The lab also records JA4_r, the raw form used by the FoxIO tooling:

t12d2709h2_002f,0033,0035,0039,003c,003d,0067,006b,009c,009d,009e,009f,c009,c00a,c013,c014,c023,c024,c027,c028,c02b,c02c,c02f,c030,cca8,cca9,ccaa_000a,000b,000d,0016,0017,0023,ff01_0403,0503,0603,0807,0808,0809,080a,080b,0804,0805,0806,0401,0501,0601,0303,0301,0302,0402,0502,0602

That makes the normalisation visible. It also shows why JA4 is not fuzzy hashing: sorting makes selected permutations equivalent, while the hashes still support equality matching rather than semantic distance.

Mercury NPF: a retained protocol tree

Cisco Mercury 2.18 emits this tls/2 fingerprint for the same ClientHello:

tls/2/(0303)(c02cc030009fcca9cca8ccaac02bc02f009ec024c028006bc023c0270067c00ac0140039c009c0130033009d009c003d003c0035002f)[(0000)(000a000c000a001d0017001e00180019)(000b000403000102)(000d002a0028040305030603080708080809080a080b080408050806040105010601030303010302040205020602)(0010000e000c02683208687474702f312e31)(0016)(0017)(ff01)]

The value is longer because it is doing another job. Parentheses and square brackets describe an ordered tree of selected byte strings. In the draft NPF notation, square brackets mark a lexicographically sorted list. The tls/2 prefix names the protocol and fingerprint rule version.

An analyst can inspect the retained values rather than relying only on a digest. Mercury also defines a compact hash nickname when a fixed-length index is needed, but that nickname loses the structure used for inspection, prefix comparison or approximate matching. Cisco's draft NPF specification documents both representations.

The Mercury JSON includes the same source and destination tuple and the same SNI as the JA3 and JA4 records. It does not identify the client application in this lab because we did not run a labelled fingerprint knowledge base or the destination-context classifier. A packet-derived NPF value and a process assessment are separate outputs.

What the comparison establishes

All three methods observe the same ClientHello, but they define similarity differently.

Question	JA3	JA4	Mercury NPF `tls/2`
Compact default	Yes	Yes	No; optional hash available
Inspectable selected inputs	Only if the pre-hash string is retained	Partly in `a`; fully in the recorded raw form	Yes in the full tree
Selected list sorting	No, after GREASE removal	Ciphers and most extensions	Rule-specific selected extensions
Explicit format version in value	No	Encoded field semantics, but no separate rule number	Yes
Semantic or approximate comparison	Not from the digest	Component grouping, not hash distance	Full structure can support richer matching
Application attribution in the format	No	No	No

The table does not produce a universal winner. JA3 remains useful where historical compatibility matters. JA4 is compact and handles selected permutations cleanly. Mercury retains more material for inspection and for analysis systems that need structured features.

It also shows what none of the values can establish. The capture does not prove which person, device or application created the connection. Shared libraries, browser impersonation and software updates all complicate that inference. See A network fingerprint is a cohort, not a client for the operational consequences.

For the history behind these design choices, read Two lineages of TLS fingerprinting. The durable format comparison is in Mercury vs JA4 vs JA3.