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_oandJA4_rowhere 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.
