Formats
The observed features, the fingerprint scheme, and the export format are different things.
A scheme turns protocol features into a value. An export format carries records in a file. A JSON or CSV file does not establish compatibility with a particular fingerprint scheme.
Fingerprint families
The inspected capture catalog describes the following families. Actual observations depend on the capture source, provider, and profile; an implemented formatter does not mean every layer is visible on a connection.
| Family | Selected behavior | Context and limits |
|---|---|---|
| TCP | TCP option features, window size, and flags. | Describes transport behavior; endpoint enrichment is separate. |
| TLS | ClientHello offers such as cipher suites, extensions, supported groups, and ALPN. | Different schemes select and normalize different features of the same handshake. |
| HTTP/2 and HTTP/3 | Client settings and request pseudo-header order; HTTP/2 also includes startup window and priority observations. | These values describe protocol structure, not request bodies or header values. Acquisition is provider-specific. |
| QUIC Initial | Initial header fields and retained transport-parameter structure. | Initial evidence alone does not reveal encrypted HTTP/3 settings or requests. |
| SSH | Identification banners and ordered key-exchange algorithm offers. | Client and server roles differ; banner text needs a separate privacy review before publication. |
The public record technical draft currently admits only the selected tls.ja3@1 and tls.mercury@1 outputs. This family overview does not add public exports, a combined fingerprint identifier, or compatibility claims.
Capture scheme notes
These notes describe inspected capture definitions, not available database exports or a compatibility certification.
| Scheme | Observed output | Compatibility limit |
|---|---|---|
tls.ja3 | Ordered decimal TLS feature string; output key ja3. | No MD5 digest. Do not compare it directly with a standard JA3 digest. |
tls.ja4 | Repository-specific TLS count and ALPN layout; output key ja4. | No standard JA4 hash layout or hashing. The name does not establish interoperability. |
tls.mercury | A truncated SHA-256 of selected TLS offer features; output key mercury. | No claim of Cisco Mercury compatibility. Helper and registered-definition encodings differ. |
A small example
This synthetic string illustrates the inspected tls.ja3 layout. It is not an observed client record, a software label, or a published database entry.
771,4865-4866,10-0,29-23,0The five fields carry the legacy TLS version, cipher suites, extension IDs, supported groups, and EC point formats. Order and normalization matter. The legacy version field is not the negotiated TLS version.
External converters need explicit contracts and test vectors before we can promise compatibility. Code, methods, and databases also have separate licensing questions.