TLS fingerprinting uses features of a connection’s handshake to recognise patterns associated with client software. At signup, those patterns can help check whether a browser claim is consistent with the connection. They cannot establish the visitor’s identity or whether that person has registered before.
Emvero’s TLS mismatch findings record disagreements with browser claims. Both are informational: they have default_raises: false and do not by themselves require email confirmation or reject a signup. Understanding what was compared helps you decide how much weight to give the finding.
What the TLS handshake reveals
When a client starts a TLS connection, it sends a ClientHello describing the capabilities it offers. These include cipher suites and extensions such as supported protocol versions and key-exchange groups. The server uses those offers during negotiation. RFC 8446’s ClientHello definition describes the structure.
A fingerprinting method selects and summarises handshake features so connections with similar software behaviour can be compared. JA3 and JA4 are named methods for doing this. A shared pattern can describe many installations of the same software; it is not an identifier assigned to one person.
Chromium’s extension-permutation proposal describes randomising the order of ClientHello extensions to avoid systems depending on an unchanging handshake. A fingerprint that preserves extension order and one that normalises it need not behave alike. Treat the pattern as an observation made under particular rules.
TLS evidence and browser or device fingerprinting
TLS evidence comes from the connection. Browser fingerprinting can combine other observable characteristics, including values measured by code running in the browser. The W3C fingerprinting guidance distinguishes passive observations from active techniques such as rendering graphical patterns. Canvas output is an example of a browser-rendering input. Audio processing supplies another kind of input, discussed in the Web Audio working draft’s privacy considerations.
These inputs can contribute to broader attempts to correlate devices or sessions. A TLS consistency finding has a narrower meaning. Emvero’s signup response does not provide a persistent Visitor ID or a raw fingerprint for you to use as an account identifier. It also does not provide a public JA3/JA4 lookup or browser fingerprint test.
A proxy that terminates TLS creates a separate connection and its own ClientHello towards the destination, as RFC 8446 explains for TLS terminators. Simply routing traffic through a tunnel does not establish that TLS was terminated. Do not assume every VPN replaces the browser’s handshake.
What Emvero compares with the browser claim
The capture infrastructure observes the connection used when the page requests a visit token. Its TLS comparisons use the User-Agent claim from that connection’s first request. Your backend later sends the visit token with the signup check; its API connection to Emvero is separate from that observed visit.
The capture service compares the claim with labels associated with the observed handshake pattern. Those labels come from the population of connections that present the pattern and the software they claim to use. They describe an association in the observed traffic, rather than a trusted declaration of which software is installed.
User-Agent and Client Hints can also disagree with each other. That is a separate comparison of HTTP claims. It does not turn either claim into proof of the browser’s engine, and it should not be confused with the TLS comparisons below.
Engine disagreement: fp_client_tls_mismatch
This finding means the engine implied by the User-Agent claim is not among the engines associated with the connection’s TLS pattern. It compares an engine claim with population labels, rather than identifying an exact browser brand. The finding is in the identity class with default_raises: false.
An application can use its own networking stack while sending a browser-like User-Agent. That can produce the same kind of disagreement as an intentionally misleading claim. The finding alone cannot distinguish those explanations.
Chromium version disagreement: fp_client_tls_version_mismatch
This finding compares the claimed Chromium major version with the version range associated with the TLS pattern. Here, “version” refers to Chromium, not to a disagreement between TLS 1.2 and TLS 1.3. The range is a version epoch inferred from the observed traffic; it does not identify the exact installed browser version.
This shortened finding uses synthetic example values. The numbers illustrate the comparison and are not a reference map for current Chromium releases:
{
"code": "fp_client_tls_version_mismatch",
"class": "identity",
"default_raises": false,
"detail": {
"direction": "claim_newer",
"epoch": "131-150",
"claimed_version": 153
}
}
claim_newer means the claim is newer than the associated epoch. It does not mean the service has measured Chromium 150 on the device. An application that names a recent Chrome version while using an older system WebView can produce this disagreement. The version finding therefore remains informational too.
Check whether the comparison ran
The absence of a mismatch finding can mean agreement, but it can also mean the comparison could not be made. Inspect not_evaluated and the available comparison status before treating an absent finding as an agreement.
fp_client_tls_not_evaluated identifies an engine comparison that could not be completed. fp_client_tls_version_not_evaluated does the same for the Chromium-version comparison. Reasons can include an unlabelled handshake pattern, unavailable labels or a User-Agent that supplies no usable claim. The corresponding status is reported under signals.client_claims.tls or signals.client_claims.tls_version when those objects are present.
claimed_engine and labeled_engine are returned as not_carried because the token does not carry those underlying engine values. That limits the reported detail, distinct from whether the comparison ran. A signals status of unavailable concerns the assessment as a whole and does not establish a safe visitor.
Use TLS findings within the signup decision
These TLS codes do not enter signal_codes as raising findings under the default policy. Other evidence can still require confirmation, and the email result can still determine a rejection. Read the returned outer action; do not infer it from one TLS finding. The signup-result explainer covers how the findings and the combined recommendation fit together.
Your application controls confirmation and account permissions. Use Signup Protection when you need email and visit evidence in that decision. The signup protection setup guide gives the form, token, server request and action sequence.