JA3 (Salesforce)

---

What JA3 (Salesforce) actually does

The original TLS fingerprint format. The specific hash construction is superseded, but it is still what a great deal of deployed detection and a great deal of tooling speaks.

What JA3 (Salesforce)'s maintenance signals mean

archived reads true, set 2025-05-01. This is the only measured field in the rubric that outranks every date rule, and it outranks them for a good reason: every other signal here is the register inferring intent from behaviour, while this one is the maintainer stating intent directly. When the two disagree, the statement wins.

An archived repository is readable, forkable and permanently frozen. Nothing will be merged into it, and no advisory affecting it will be answered there. That makes it a reference rather than a dependency — genuinely valuable as the former, and a liability as the latter. The last push date is still printed above, because the interval between the last commit and the archive flag is itself informative about how the project ended.

No release was captured for this entry, which this register records as unknown rather than as none. The distinction matters more than it looks: a project with no tags and a project whose tags the sweep failed to read produce the same blank cell, and printing them as the same fact would be the register asserting something it has not measured.

Where JA3 (Salesforce) sits in this catalogue

JA3 (Salesforce) is filed in section 07, network, tls & http fingerprint tooling, whose scope is this: The layer below JavaScript: TLS ClientHello and HTTP/2 fingerprinting, impersonating clients, and the passive tooling that reads them. An entry sits in exactly one section here. Where a project could defensibly go in two, it is placed where a reader would look for it first rather than where it fits most tidily, and that is an editorial decision rather than a measured one.

Filed beside it in the same section: JA4+ (ACTIVE), JA4+ explainer (ACTIVE), JA3 origin writeup (ACTIVE). Comparing an entry against its own section-mates is more informative than comparing it against the catalogue as a whole, because everything in a section is answering roughly the same question and the differences left over are the ones that matter.

It is published under BSD-3-Clause, alongside the rest of the BSD-3-Clause entries in this register, and it sits with everything else currently marked ARCHIVED. Read those two facets together: a permissively licensed project that stopped shipping is not a safer dependency than a copyleft one that did not, and a filter on one axis alone will tell you the wrong thing.

This register records that JA4+ supersedes JA3 (Salesforce). Supersession here is declared, never inferred: it is printed only where a project or its author says so, because "newer" and "replaces" are not the same relation and treating them as one is how a list starts recommending rewrites nobody asked for.

The JA3 (Salesforce) relations page sets every declared edge side by side on licence, push date, release cadence and derived state.

What to settle before you adopt JA3 (Salesforce)

The repository is archived by its corporate owner, which is a maintainer statement and outranks every date rule in this register's rubric. The format outliving its reference implementation is the situation to plan around.