TLS fingerprint

The fingerprint of the encrypted connection itself.

What this check is

Before any HTTP is exchanged, the browser and the server negotiate an encrypted connection, and the way a client opens that negotiation is characteristic of the software doing it. Fingerprints of that handshake (JA3, and its successor JA4) effectively name the TLS stack: this browser family, that HTTP library, some other tool entirely.

What Tells reads

The TLS version of the connection
The JA4 (or JA3) fingerprint Cloudflare computed for it, when the plan exposes it

How to read your result

Pass / informational: Tells displays the fingerprint but does not score it: on its own it identifies a class of software, not a culprit.
Not available: Cloudflare did not return a JA4 or JA3 fingerprint for this request, so the row says so rather than guessing.

Why it matters

TLS fingerprints matter because they are so hard to argue with. A request can claim any User-Agent it likes in a header, but if the handshake is the one a Python HTTP library makes, the claim and the connection disagree, and sites with bot management compare exactly that pair. Real browsers are consistent here without trying, because the same engine makes both.

Where this matters most

Across the platforms Blowhorn works with, rated in the platform guide (H = matters a lot, M = contributes, L = no public evidence; tags mark vendor-stated, reported, or inferred evidence):

LinkedIn (M): standard in anti-fraud stacks at this scale; not publicly documented for LinkedIn [Inference]
X (M): same reasoning; not publicly documented for X [Inference]
Reddit (M): edge blocking of non-browser clients is consistent with TLS and HTTP fingerprinting [Inference]

Everywhere else in the set this one rates Low.

In your report

Find it in the checks table on the tool page, with the detail in the Server / IP section. The same findings appear in the report JSON under verdict.reasons, and the agent guide explains how to read them programmatically.