Detecting curl-impersonate and uTLS: the second-order tells

Library-specific residue

Even when a tool patches the HTTP/2 settings and fixes the header order, it leaves residue. Residue is the set of small behaviours that come from the specific library doing the impersonating rather than from the browser it claims to be. Two stacks can produce the same fingerprint string and still behave differently in ways a careful detector can observe.

The clearest example is the “unknown random setting” the lwthiker author noticed in Chrome’s SETTINGS frame. A faithful impersonation has to reproduce whatever that parameter is, with whatever value Chrome uses, in the right position. Get the value wrong, or omit it, or place it in the wrong order, and the SETTINGS string no longer matches even though the impersonation tried. Chrome’s choices here are tied to its build and change across versions, so a static profile baked into a tool at one point in time can fall out of sync with the browser it copies.

Timing and framing residue is subtler. The Akamai fingerprint cares about the connection-level WINDOW_UPDATE and any PRIORITY frames, but a real browser also exhibits a characteristic rhythm: when it sends the WINDOW_UPDATE relative to the preface, how it sizes per-stream flow control, whether it coalesces requests onto one connection or opens several. A library reproduces the static fingerprint far more easily than it reproduces this dynamic behaviour, because the static fingerprint is a fixed string to copy and the behaviour is an emergent property of a different codebase. None of the public vendor documentation lays out exactly which dynamic signals are scored or how they are weighted; what is documented is that the SETTINGS, WINDOW_UPDATE, and PRIORITY frames feed the fingerprint, and what is reasonable to infer is that a stack which gets the string right can still get the timing wrong.

There is also residue at the TLS layer that survives a correct JA3 or JA4. The hashes deliberately ignore some fields. JA3 does not capture the contents of GREASE values (it filters them out, which is the entire reason GREASE breaks naive fingerprinting), and neither hash captures everything in the record layer or the exact bytes of every extension’s payload. A detector that goes beyond the published hash and inspects the raw ClientHello can find places where a forgery is structurally correct but not bitwise identical to the browser. Cipher suite order is in the hash, so a tool has to get cipher ordering exactly right, but the long tail of fields the hash skips is exactly where a library that is “close enough for JA4” stops being close enough for a raw-bytes comparison. This is the cipher-stunting problem in reverse: where attackers once randomized ciphers to escape JA3, defenders now look past JA3 at the fields it never covered.

A different flavour of residue lives below the TLS layer, at TCP and IP. The operating system that terminates the connection sets the initial window size, the TCP options and their order, the window scale factor, and the TTL on outbound packets, and those choices are an OS fingerprint independent of anything the application does. FoxIO published JA4T and JA4L for exactly this, capturing TCP options and a latency-derived distance estimate. The point for impersonation is the consistency check it enables. A User-Agent claiming Chrome on Windows, riding a TLS fingerprint for Chrome on Windows, arriving over a TCP stack whose options say Linux, is internally inconsistent. The tool runs on a Linux server; the OS it claims is Windows; and the TCP layer is the one part of the stack a userspace HTTP client cannot easily rewrite, because it belongs to the kernel. That makes the network-stack fingerprint a stubborn honest layer underneath a forged one. How much weight any given vendor puts on it is not documented, and a proxy or load balancer in the path can rewrite enough of it to muddy the signal, so treat this as a corroborating tell rather than a decisive one.

HTTP/3 moves the same problem onto QUIC

HTTP/3 does not erase any of this. It reimplements HTTP/2’s semantics over QUIC, and QUIC carries its own initial parameters: the transport parameters in the QUIC handshake, the order and presence of frames, the way the client paces and acknowledges. Those are as fingerprintable as the HTTP/2 SETTINGS frame, and arguably more so, because the QUIC stack is younger and the implementations diverge more. curl-cffi’s own documentation notes that HTTP/3 fingerprinting has not been as widely exploited in production as HTTP/2, and that some operators see lower detection over HTTP/3 today. That gap is a function of deployment maturity, not of any property that makes QUIC harder to fingerprint. As vendors finish wiring QUIC parameters into their scoring, a tool that forges the TLS-over-QUIC handshake but uses its library’s default QUIC transport parameters inherits exactly the cross-layer seam this whole post is about, one protocol over. The structural problem does not go away when the transport changes. It moves.

Version drift, the tell that arrives on its own

The most reliable signal against impersonation tools is the one that needs no cleverness at all. It just waits.

A browser fingerprint is a snapshot of one build. Chrome’s ClientHello, its SETTINGS frame, its Sec-CH-UA brand list, its supported groups: all of it moves as the browser ships new versions. When Chrome 124 added the X25519Kyber768 post-quantum key share (later X25519MLKEM768), every real Chrome on the planet started sending it within a release cycle or two, and a profile that predated it instantly looked like an old browser. The same happened with Brotli certificate compression, with ZSTD support in Chrome 123, with ECH support, with each change to the extension set. Chrome’s own extension order is randomized per-connection now, a change that broke JA3, so a tool that emits a fixed extension order is anomalous against a browser that shuffles.

Impersonation tools update on a different clock than browsers do. The original lwthiker curl-impersonate stalled; its last release, v0.6.1, shipped in March 2024 with profiles topping out around Chrome 116 and Firefox 117. The browser kept moving. By 2026 a request claiming Chrome via a 2024-era profile sits in a strange place: the User-Agent says a current version, the TLS fingerprint says a year-old one, and no real population of users looks like that. The active fork by lexiforest exists precisely because someone had to keep chasing the browser, and it carries profiles up through recent Chrome, Firefox, and Safari builds for exactly this reason. The fork’s existence is the clearest evidence that drift is the dominant failure mode. If a static profile aged gracefully, nobody would need to keep re-cutting it.

Drift cuts the other way too, and this is the subtle part. To stay current a tool has to update its whole bundle in lockstep: TLS profile, HTTP/2 settings, header order, and Sec-CH-UA brand list all need to advance to the same version at the same time. Update the User-Agent string but not the supported groups and you have manufactured a mismatch by hand. The version a request claims has to be consistent across every layer simultaneously, which is a much harder invariant to hold than getting any single layer right once. A real browser holds it for free because all the layers come from one build. An impersonation stack assembles those layers from different sources and has to keep them aligned by discipline.

How a detector wires the consistency check

It helps to see the check from the defender’s side, because once you do, the reason a perfect ClientHello does not save the request becomes mechanical rather than abstract. A detector that sits at the edge sees every layer of the connection in one place: it terminates TLS, so it has the raw ClientHello; it speaks HTTP/2, so it has the SETTINGS frame and the window updates; it parses the request, so it has the headers in order. From those it computes a handful of fingerprints and then asks one question across them.

1
ja4   = fingerprint(client_hello)         # -> a browser + version family
2
h2    = akamai_h2(settings, wu, prio, ps) # -> a browser + version family
3
ja4h  = fingerprint(request_headers)      # -> a browser + version family
4
claim = parse(user_agent, sec_ch_ua)      # -> the browser + version asserted
5

6
if not all_agree(ja4, h2, ja4h, claim):
7
    raise InconsistentClient

The interesting work is inside all_agree. It is not a string compare. Each fingerprint maps to a known set of browser-and-version families, maintained from real traffic and from running the browsers in a lab. The question is whether there exists a single browser build that would have produced all four observations at once. For a real Chrome, that build exists by construction, because all four came from it. For a tool that forged the ClientHello but let its HTTP library do the rest, no single build satisfies the system: the ClientHello points at Chrome 146, the SETTINGS frame points at nghttp2 or Go’s net/http, the header order points at the library’s defaults, and the User-Agent points wherever the operator typed. The detector does not have to know the tool. It only has to find that the intersection of the four candidate sets is empty.

This is why adding more fingerprints strictly helps the defender and strictly hurts the forger. Every layer the detector scores is one more constraint the forgery has to satisfy simultaneously. A tool that patches the ClientHello satisfies one constraint. A tool that also patches the HTTP/2 settings satisfies two. To satisfy all of them at once it has to reproduce a complete, coherent browser across every observable layer, at a specific version, with no piece lagging, which is most of the way to just running the browser. The cost curve bends against impersonation as the number of independent layers grows, and the JA4+ suite was designed around exactly that arithmetic. Cloudflare, Akamai, and DataDome each describe variations of the same multi-layer consistency model in their public writing on TLS and HTTP/2 scoring, and the server-side-versus-client-side breakdown covers where this check sits relative to the JavaScript probes that run later.

The defender’s check has a cost of its own, and it is worth naming honestly. Computing four fingerprints per connection and intersecting candidate sets is more expensive than hashing one ClientHello, and the candidate-set databases have to be kept current as browsers ship, or the consistency check starts producing false positives against real, freshly-updated browsers. That maintenance burden is the mirror image of the forger’s drift problem. Both sides are running to keep up with the browser. The asymmetry is that the defender only has to recognize the browser, while the forger has to reproduce it, and recognizing is cheaper than reproducing.

Where the public record ends

A note on certainty, because the brief for this kind of reference is to be honest about the edges. The structure of these fingerprints is public. The Shuster HTTP/2 format, the JA3 and JA4 algorithms, the JA4H layout: all published, all reproducible against your own captures with open-source tools. What is not public is the scoring. No vendor documents the exact weight it puts on an HTTP/2 mismatch versus a header-order mismatch, the threshold at which a contradiction becomes a block rather than a challenge, or the full set of dynamic behavioural signals it watches on the connection. Those are inferred from vendor blog posts, from the structure of the fingerprints, and from observed behaviour, not read from a spec. Where this post named a specific value (Chrome’s m,a,s,p pseudo-header order, the 15663105 window increment, the v0.6.1 release date), that came from a fetched source. Where it described how scoring combines the layers, that is the reasonable inference, and it is labelled as such.

The seam is the signal

The thing to take from all of this: a perfect ClientHello is necessary and nowhere near sufficient. curl-impersonate and uTLS solved the TLS layer years ago, and that solution is real. JA3 and JA4 alone cannot tell their output from a browser. But detection stopped living at the TLS layer the moment vendors started computing a second fingerprint one frame later, in the HTTP/2 SETTINGS, and a third in the header order, and cross-checking all of them against the version the User-Agent claims. The forgery is total at the bottom of the stack and partial above it, and the detector scores the disagreement.

That structure has a property worth sitting with. It does not require the detector to recognize any specific tool. It does not need a blocklist of known-bad fingerprints or a signature for curl-impersonate or for uTLS. It only needs to notice that a request’s TLS layer claims one identity while its HTTP/2 frames, its headers, and its version claims point somewhere else. A new impersonation library that nobody has seen still has to assemble its layers from separate pieces of software, and unless every one of those pieces is patched into agreement and kept in lockstep with a browser that ships a new build every few weeks, the seam shows. The cheapest tell of all, version drift, costs the detector nothing and arrives on schedule whether anyone is watching or not.

Sources & further reading

• Elad Shuster et al. (2017), Passive Fingerprinting of HTTP/2 Clients — the Akamai Black Hat EU whitepaper defining the four-part HTTP/2 fingerprint (SETTINGS, WINDOW_UPDATE, PRIORITY, pseudo-header order).
• lwthiker (2022), Impersonating Chrome, too — the curl-impersonate author on patching BoringSSL, GREASE, ALPS, and the HTTP/2 SETTINGS gaps, including Chrome’s “unknown random setting”.
• Daniel Stenberg (2022), curl’s TLS fingerprint — curl’s author on what determines a client’s TLS fingerprint and the arms race around mimicking browsers.
• Akamai SIRT (2019), Bots Tampering with TLS to Avoid Detection — Akamai on cipher stunting and why temporal, cross-layer analysis beats static JA3.
• John Althouse / FoxIO (2023), JA4+ Network Fingerprinting — the JA4+ suite and the argument that combining fingerprints across layers defeats single-layer spoofing.
• FoxIO (2023), JA4H technical details — the JA4H HTTP-client fingerprint format, including header-order hashing.
• FoxIO (2024), JA4T: TCP Fingerprinting — fingerprinting the TCP layer (window size, options, scale) as an OS signal independent of the application.
• lexiforest (2024-2026), curl-impersonate (active fork) — the maintained fork tracking newer Chrome, Firefox, and Safari profiles, ECH, ZSTD, and post-quantum curves.
• lwthiker (2024), curl-impersonate — the original project; v0.6.1 (March 2024) tops out near Chrome 116, illustrating profile drift.
• Scrapfly (2025), HTTP/2 and HTTP/3 Fingerprinting: Protocol-Level Bot Detection — worked examples of Chrome vs Firefox HTTP/2 fingerprints and the cross-layer validation model.
• Trickster Dev (2023), Understanding HTTP/2 fingerprinting — a clear breakdown of the Shuster fingerprint components with examples.
• wi1dcard (2023), fingerproxy — an open reverse proxy that computes JA3, JA4, and the Akamai HTTP/2 fingerprint and forwards them as headers.
• curl_cffi (2026), TLS, HTTP/2 and HTTP/3 fingerprinting — documentation on how the Python binding reproduces browser fingerprints across layers.