JA4 fingerprint
t13d691200_8b2139ff7677_0ceea7c49f79
Netskope - an enterprise TLS-inspection proxy.
TCP · TLS 1.3, domain present, 69 cipher suites, 12 extensions, none offered ALPN.
Anatomy
8b2139ff7677 is a SHA-256 of the sorted cipher list · 0ceea7c49f79 covers the extensions and signature algorithms. Hashes aren't reversible - the identity below comes from matching them.
Identity
from reference DBThis exact JA4 string is in our reference database, so it's a confident, byte-for-byte match for Netskope.
Get hundreds of insights
connection_fingerprint: {ja4: {hash: "t13d691200_8b2139ff7677_0ceea7c49f79",family: "middlebox",product: "netskope",},user_agent_alignment: "?", // needs a live requesth2_fingerprint: "?", // needs a live request}
A JA4 is one clue. Foil checks hundreds more - the network, the device, and how the session behaves - and tells you when they don't add up. That's usually where the bots are.
See it on a real session - free →What to do
AttributeThis is an enterprise SSL-inspection proxy re-originating TLS on behalf of the browsers behind it, so the handshake describes the proxy - every employee on that network presents this JA4 under every User-Agent.
Don’t score the TLS-vs-UA mismatch as spoofing: you’d flag entire companies of real users. Attribute the traffic to the gateway (the egress IPs usually belong to the vendor), rely on signals the proxy doesn’t rewrite - JavaScript environment, behavioral input, HTTP-layer fingerprints - and only escalate if those disagree too.
About this fingerprint
This fingerprint belongs to Netskope - an enterprise secure web gateway that terminates the browser's TLS at the network edge and re-originates the handshake from its own stack. The JA4 therefore describes the proxy, not the browser behind it: one handshake speaking for Chrome, Edge, and Firefox users on the same corporate network, under every one of their User-Agents.
This entry is production-verified: Foil has observed this exact fingerprint across multiple customer networks with consistent client-hint corroboration, and catalogued it in the product's reference tier - it isn't in the public database export at all.
The breakdown above is computed from the string itself: the readable JA4_aprefix gives the transport, TLS version, SNI flag, cipher and extension counts, and ALPN, while the two hashes are matched against Foil's reference database to name the client. For the full background, see TLS fingerprinting, or try any fingerprint of your own in the JA4 database.
Both component hashes can be looked up on their own: cipher hash 8b2139ff7677 lists every fingerprint built on this cipher stack.
Corporate SSL-inspection traffic is the classic false-positive trap for TLS fingerprinting: thousands of real employees behind one OpenSSL-style handshake that matches no browser. Treating the mismatch as spoofing flags whole companies as bots - which is why Foil classifies known inspection stacks explicitly instead of scoring them as tampering. See TLS fingerprinting for how the cross-checks work.
Frequently asked
JA4 is a fingerprint of the TLS ClientHello a client sends before any HTTP. It is a three-part string, JA4_a_JA4_b_JA4_c: a readable prefix (transport, TLS version, SNI, cipher and extension counts, ALPN) followed by two truncated SHA-256 hashes over the sorted cipher and extension lists. Unlike JA3, it survives Chrome's extension-order randomization.
The JA4_a prefix decodes by eye: the first character is the transport, the next two are the TLS version, then SNI, a two-digit cipher count, a two-digit extension count, and the first ALPN value. The two hashes are not reversible; you identify them by matching against a database or by decoding the raw (JA4_r) variant.
A JA3 fingerprint is an MD5 hash of the handshake, so the hash itself carries no readable structure. Only the raw JA3 string (version, ciphers, extensions, curves, point formats) can be decoded back into its components.
Yes. Fingerprints are matched against a distilled reference database of common browsers, HTTP libraries, and automation tools. The match tells you what a client is; identifying whether it is lying about that requires cross-checking against the User-Agent, HTTP/2 fingerprint, and JavaScript environment in a live request.