Peakhour.IO - Security Research

When a Proxy Network Dies but Its IPs Survive

2026-08-03T08:30:00+10:00

A residential proxy network goes dark. Its domains are seized, its control systems are disrupted and its branded pool almost disappears. Two weeks later, many of the same public IP addresses appear through other proxy services.

Did the takedown fail? Did the same devices move? Were several providers selling the same supply all along?

The honest answer is narrower: the address inventory overlapped across time. That is valuable evidence, but it is not device identity, ownership or motive.

This distinction matters to security and fraud teams deciding what to do with traffic. It also matters to buyers, auditors and researchers trying to establish whether a proxy provider controls the supply chain it describes.

One Address Sits Above Several Relationships

The destination website sees the last layer in a longer chain:

device -> public IP -> SDK or supplier -> proxy pool -> reseller -> buyer -> destination

Each arrow represents a separate relationship.

The device may be a phone, laptop, streaming box, household gateway or server. Software on it, or elsewhere on the same network, sends a buyer's traffic out through a public IP assigned by an ISP or mobile carrier.

An SDK or supplier enrols that capacity. A proxy pool makes it selectable. A reseller may buy the service upstream and sell it under another name. A buyer chooses a location or session through an API. The destination sees a request from the exit address, not this commercial history.

Those layers do not map one-to-one. Several devices can share one public address through a household router or carrier-grade NAT. One device can receive different addresses over time. One supplier can feed several pools. A pool can combine direct supply with upstream inventory. A reseller may not know which device, supplier or SDK produced a particular session.

Our article on how bandwidth sharing feeds residential proxy networks covers the ways capacity enters this chain. The question here is different: what can we infer when a named network disappears but addresses associated with it remain visible elsewhere?

What the NetNut Measurement Found

On 2 July 2026, Google, the FBI, Lumen and other partners took action against the NetNut residential proxy network, also known as Popa. Our comparison of the IPIDEA and NetNut actions separates the controls and public claims involved. Google said it disabled accounts and services used for command and control, shared technical intelligence, and updated Play Protect to disable applications known to contain NetNut SDKs. Google estimated that the network included at least two million devices and said it had high confidence that multiple proxy brands white-labelled NetNut capacity.

Layer3 Intel then published a useful post-event measurement. Its NetNut takedown analysis says the number of unique NetNut exit IPs it observed per hour fell by 99.92% by 5 July. At the brand or gateway layer, that is a decisive decline.

The cross-network result was less absolute. Layer3 Intel took IPv4 addresses it had observed through NetNut in the 30 days before the shutdown and checked whether they appeared through other networks during the following 14 days. Among addresses seen through NetNut in the final one to two days, 78.81% reappeared elsewhere.

The researchers also tried to account for ordinary churn. They applied reappearance rates from a 4 June placebo cutoff to the July cohort. On that basis, they expected about 17.96 million recent addresses to reappear and observed 16.90 million. The difference produced a baseline-adjusted estimate of about 1.06 million IP addresses removed from the wider proxy ecosystem beyond normal churn.

These measurements support three bounded findings:

NetNut's branded, observable exit service collapsed.
Much of the recent public-address inventory associated with NetNut was observable through other proxy networks after the disruption.
Reappearance was lower than the selected June baseline, consistent with a real takedown effect beyond ordinary address churn.

That is already operationally important. A provider name can disappear while some of the address inventory remains commercially reachable.

An IP Match Is Not a Device Match

The same measurement does not prove that the same physical device survived, moved between suppliers or carried two SDKs.

Public addresses are assigned to connections, not permanently engraved on devices. DHCP leases expire. Mobile subscribers move between network gateways. Consumer routers reconnect. Carrier-grade NAT lets many subscribers share public addresses from a provider-controlled pool. RFC 6598 documents shared address space used by service providers for CGNAT, but the ambiguity exists outside that range too: the destination only sees the translated public address.

If 203.0.113.x appears through Network A before a cutoff and Network B afterwards, several explanations fit:

the same device was available through both networks;
different devices behind the same household or carrier address were enrolled;
an ISP reassigned the address to a different subscriber;
a shared upstream supplied both pools;
one provider resold another provider's capacity;
the enumeration system attributed one of the observations incorrectly.

IP overlap increases confidence that address inventory is shared or recycled across the market. It does not identify which explanation is correct for any one address.

It also does not prove supplier ownership. A provider may own infrastructure, contract directly with a supplier, buy capacity through an intermediary, or combine all three. Nor does overlap prove that a device owner did not consent. Consent belongs to a specific person, device, software version, disclosure and time. An IP address contains none of those records.

Most importantly, overlap does not prove motive. It can show that a buyer's request travelled through an observed exit. It cannot establish what the supplier, reseller or provider knew, why a buyer selected the route, or whether the destination request was benign or abusive.

Google's earlier IPIDEA investigation reached beyond address overlap. It analysed applications, Windows binaries, SDK code, command infrastructure and shared server pools, and paired that technical work with platform and legal action. Even then, Google noted that overlaps between exit nodes made definitive quantification and attribution difficult. That is the right standard: use IP observations as one part of a multi-layer attribution, not as a shortcut through the layers.

Read the 1.06 Million Estimate as an Estimate

Layer3 Intel's analysis is stronger than a simple before-and-after count because it recognises ordinary churn and uses an age-matched comparison. Its scale and high-frequency observation also give it a useful view of the market.

The public methodology still leaves material uncertainty:

Enumeration is proprietary. The post describes the volume and timing of observations, but does not publish the complete sampling system, provider coverage, request selection, deduplication rules or validation set. Readers cannot independently reproduce the population from the article alone.
An IP is a noisy unit. Dynamic addressing and CGNAT break a stable link between address, subscriber and device. Counting distinct IPv4 addresses can overstate devices and obscure shared use.
The windows choose what can reappear. The source cohort covers 30 days; the follow-up covers 14. Shorter or longer windows would change both the raw overlap and the churn model.
There is one published placebo cutoff. A single June comparison is useful, but it does not show the normal week-to-week distribution, seasonal effects or whether that period was representative.
No confidence intervals are published. The 1.06 million figure is presented as a point estimate. The post does not provide uncertainty bounds, sensitivity analysis or an error rate for network attribution.
The counterfactual is observational. The difference from baseline is consistent with the takedown removing capacity. Other simultaneous supplier, demand, enforcement or measurement changes could contribute.

None of these limits makes the result useless. They set its resolution. “About 1.06 million fewer addresses reappeared than this baseline predicted” is supported by the published method. “Exactly 1.06 million devices were removed” is not.

What a Sourcing Claim Can Responsibly Prove

A vendor can responsibly prove facts about processes and records it controls.

It can show which entity contracted each direct supplier, which software package enrolled a device, what disclosure was presented, how affirmative consent was recorded, how withdrawal works, which versions were active, and whether a buyer's session can be traced to that evidence. It can document reseller dependencies, prohibit undisclosed sub-supply, test compliance and publish exceptions.

A policy page can prove that a policy exists. A contract can prove that parties accepted terms. Neither proves that every active exit followed the policy.

“Ethically sourced” is therefore too broad unless the provider defines the claim and its coverage. Does it apply only to a proprietary pool? To upstream suppliers? To every session sold by resellers? Does consent come from the device user, the account holder, the network owner or all relevant parties? How quickly is an exit removed after withdrawal?

The strongest claim is session-level and time-bound: for this delivered connection, the provider can trace the supply path to a named enrolment mechanism and current evidence, subject to stated audit limitations. Anything less should be described at its actual scope.

What Auditors and Buyers Should Request

Do not ask only whether sourcing is ethical. Ask for evidence that follows the chain:

a current inventory of direct suppliers, upstream pools and white-label dependencies;
the percentage of delivered traffic covered by direct, auditable sourcing rather than policy language alone;
SDK names, package hashes, versions, distribution channels and signed build provenance;
the exact user disclosure and consent event, including timestamp, software version and withdrawal path;
proof that the person giving consent had authority over the device and network connection;
controls for CGNAT, reassigned addresses, duplicate exits and concurrent appearance across providers;
session-level lineage from buyer request to pool, supplier and enrolment record, sampled by an independent auditor;
contractual limits on sub-suppliers, plus evidence that those limits are tested;
complaint, removal and incident records, including time to disable an exit across every downstream reseller;
methodology for advertised pool size, unique-IP counts and active-device counts, with uncertainty and deduplication rules;
independent test results, exceptions and remediation, not only a clean summary statement.

Buyers should also keep their own record: product and upstream named at purchase time, contract revision, stated sourcing basis, session identifiers where available, destination and purpose, and the control used to prevent abuse. A provider's assurance does not transfer accountability for how the buyer uses the route.

Defenders Still Have a Request to Judge

Post-takedown research can improve proxy intelligence. It cannot turn an IP address into a verdict.

An address that reappears across pools may deserve closer observation, especially on login, account recovery, checkout or expensive APIs. The action should still depend on route, account state, client consistency, behaviour and recent outcomes. That is why a proxy flag is not a security policy.

Keep the provenance of the observation as well. Record which network label was seen, when it was observed, which dataset and version supplied it, what other evidence changed the action, and what happened next. Our guide to residential proxy decision logging sets out that operating record.

A takedown can kill a service without retiring every address that passed through it. The surviving IPs tell us that the market has shared, changing inventory. To say who supplied it, whether a device owner consented, or why a request was sent, we have to follow the rest of the chain.

For the destination, the work continues with the request. The final article in this series explains why a proxy takedown is not a security control and what security and fraud teams should rebaseline after a disruption.

Before JA3: How TLS Handshakes Became Fingerprints

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

JA3 is often treated as the beginning of TLS fingerprinting. It was not. Its real contribution was narrower and, operationally, just as important: JA3 took a set of ideas that had been explored for years and turned them into a small identifier that ordinary security tools could carry.

The path to that format runs through an SSL Labs experiment in 2009, an experimental p0f extension in 2012 and Lee Brotherston's FingerprinTLS work in 2015. Each step answered a different question. What can the cleartext handshake reveal? Which details survive often enough to identify a client? How do you turn those details into something an analyst can match? And, finally, how do you make the result portable?

This is a documented lineage where the authors themselves cite the earlier work. The claim that JA3's decisive move was simplification is our interpretation of those sources, not a claim that every project shared one design plan.

2009: the cipher list as a client signature

In June 2009, Ivan Ristić described an experiment in HTTP client fingerprinting using SSL handshake analysis. He was working on SSL Labs and noticed a useful property of the initial handshake: clients sent different lists of supported cipher suites, and those lists were visible before encryption began.

The important observation was not that any one cipher identified a browser. It was the combination of ciphers a client offered. Ristić recorded the entire list as a signature and compared it with the HTTP User-Agent seen after the connection was established. He then published examples collected from real SSL handshakes, showing that the approach could separate a range of browsers, command-line clients and crawlers.

This early method was deliberately modest. It concentrated on the cipher-suite list. It did not define a general-purpose fingerprint containing every useful ClientHello feature, and it did not claim that a signature proved the identity of a process.

Even so, the core technical idea was in place:

unencrypted ClientHello
  -> implementation-dependent choices
  -> repeatable signature
  -> comparison with previously observed clients

The handshake was no longer just cryptographic setup. It was passive metadata about the software constructing it.

2012: p0f adds order, extensions and matching rules

Marek Majkowski pushed the idea further in his 2012 SSL fingerprinting patch for p0f. p0f was already known for passive operating-system fingerprinting at lower layers. Majkowski applied a similar signature-and-database model to SSL and TLS ClientHello messages.

His post explicitly credits Ristić's 2009 work, then points to two details he believed deserved more attention: ordering and TLS extensions. The patch represented a fingerprint as four fields:

requested version : ordered ciphers : ordered extensions : flags

That is a meaningful technical step. Cipher suites are normally sent in preference order, and extension order can differ between implementations. Retaining those sequences gives the signature more discriminatory power than an unordered inventory. The flags recorded other behaviours, such as compression support or an unusual relationship between record and handshake versions.

The implementation did more than print a string. It matched the result against a database of signatures that could contain wildcards and return a browser family, possible versions and sometimes a platform. The original p0f patch and notes are still useful because they expose the boundary between observation and label: one part generates the raw signature; another compares it with knowledge gathered elsewhere.

Majkowski also wrote with appropriate caution. His notes say that a ClientHello can sometimes identify the underlying SSL library and, for software with a custom build or distinctive feature set, may narrow the application version. "Sometimes" matters. Two applications using the same TLS stack can look alike, while one application can change its handshake when its library, configuration or build changes.

The p0f work did not become the universal exchange format for TLS fingerprints. It did, however, demonstrate most of the ingredients that later systems would reuse: selected fields, preserved order, a serialised signature and a separate matching database.

2015: FingerprinTLS turns a method into a toolset

Lee Brotherston's 2015 work expanded the practical surface again. His DerbyCon and SecTor presentation, Stealthier Attacks and Smarter Defending with TLS Fingerprinting, examined TLS fingerprinting from both sides: defenders could recognise unexpected software, while an operator could alter a client's handshake to blend in or evade a simplistic rule.

The associated FingerprinTLS repository packaged the approach into several working parts:

FingerprinTLS detected TLS sessions on a live interface or in a PCAP, created fingerprints and matched them;
fingerprints.json stored the known fingerprint database;
Fingerprintout exported observations into other forms, including Snort and Suricata rules.

This was broader than calculating a digest. It was a workflow for capturing a handshake, retaining many of its characteristics, associating that observation with known software and moving the result into operational tools.

The project also made an awkward truth visible: rich fingerprints are not especially convenient interchange formats. FingerprinTLS could inspect more detail, but exporting that detail into a rule language could lose accuracy. Its README warned that Snort and Suricata exports might require tuning because their rule syntax could not express the full matching logic.

That trade-off set the stage for JA3. A detailed signature helps an analyst explain why two handshakes differ. A compact value is easier to add to a connection log, compare across sensors and share with another team. It is difficult to optimise one representation for both jobs.

2017: JA3 chooses portability

Salesforce open-sourced JA3 in 2017. John Althouse's original JA3 announcement directly cites Ristić's 2009 post and Brotherston's 2015 research. It also states the team's design requirement plainly: the result had to work with existing monitoring systems and load balancers, be independent of the destination, and be easy for other tools to consume.

JA3 selected five ordered ClientHello feature groups:

TLS version,
cipher suites,
extension types,
supported groups,
elliptic-curve point formats

It rendered their numeric values into a comma-separated string, removed GREASE values, then calculated an MD5 digest. A long handshake description became a 32-character identifier.

MD5 was not being used here to protect a password or prove integrity. It was a compact naming function. The security weakness of MD5 still means a JA3 value should not be treated as proof, but changing to a stronger digest would not solve the more common identification problem: unrelated software can naturally produce the same selected features, and software can deliberately copy another client's ClientHello.

The simplification was substantial. Compared with FingerprinTLS, JA3 retained fewer fields and discarded the explanatory structure once the string was hashed. Compared with the p0f patch, it did not carry matching wildcards or classification rules in the fingerprint. What it gained was a common unit that could fit almost anywhere an operator could put a string.

That was why JA3 travelled. A sensor could calculate the value, a SIEM could index it, an intelligence report could publish it and a rule could match it without every participant adopting the same fingerprint database or packet parser.

What JA3 inherited, and what it left behind

The documented history supports a few specific claims:

Ristić showed in 2009 that an unencrypted SSL handshake, particularly its cipher list, could distinguish HTTP clients.
Majkowski's 2012 p0f work explicitly built on that experiment and added ordered extensions, behavioural flags and database matching.
Brotherston's 2015 research and FingerprinTLS made detailed capture, matching, creation and export available as a standalone toolset.
Salesforce cited the earlier work when it released JA3 and designed a smaller representation for existing operational systems.

It does not support treating a fingerprint as an application identity. Every stage depended on a set of observed features and, when a software name was returned, knowledge collected outside the handshake itself. The label could be useful without being certain.

That distinction is easier to see when the formats are run side by side. Our reproducible lab feeds one ClientHello to JA3, JA4 and Cisco Mercury and records both the compact outputs and the detail each format preserves.

JA3 was not the final step either. JA4 later changed the normalisation and output structure to cope with modern sources of instability, while Cisco's research followed a more structured, context-aware path. Those are separate branches, not one straight succession. We trace them in Two Lineages of TLS Fingerprinting.

The useful lesson from the early history is not who coined the first fingerprint. It is that the representation determines the work you can do with it. Rich detail helps investigation. Compact identifiers help distribution. Neither turns a handshake into an identity document.

What an Open Network Fingerprint Database Should Publish

2026-07-13T09:28: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.

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

2026-07-13T09:28: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.

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.