TLS Fingerprints and the Post-Quantum Shift: How a Fake Browser Gives Itself Away

By late 2025 more than half of web traffic had gone post-quantum. A client claiming a modern browser without the matching key exchange gives itself away by that field.

2026-08-31 GIGATAP Team #vpn
#vpn#anticensorship#tls#fingerprint#post-quantum#reality

TLS Fingerprints and the Post-Quantum Shift: How a Fake Browser Gives Itself Away

Imitating a browser underpins most modern transports. The logic is plain: if the handshake looks like Chrome’s handshake, telling it apart from Chrome is hard. The problem is that the Chrome handshake is a moving target. It changed enough during 2025 that older imitations now stand out more than the original they copy.

Over 2025 the ground shifted under that logic, and many configurations have not noticed.

What is a handshake fingerprint?#

When opening a secure connection, a client sends a message listing its capabilities: protocol versions, cipher suites, extensions, supported groups, application-protocol preferences.

That set — and the order of its elements — differs between implementations. A compact fingerprint is computed from it; well-known hashing schemes for this have been in use by observers for several years.

Hence a consequence familiar to anyone who has configured camouflage: faking only the requested site name is not enough. The name can be flawless while the extension set betrays a library no browser uses.

That is exactly why libraries exist that reproduce the handshakes of common browsers. Transports such as REALITY rely on them and let you choose which browser to present as.

What changed in 2025#

Post-quantum key exchange stopped being an experiment and became the majority.

Per Cloudflare Radar’s year-in-review data, the share of post-quantum human web traffic grew from 29% at the start of 2025 to roughly 52% by early December. The hybrid scheme adds a noticeable amount to the client message — on the order of a thousand-odd bytes.

That reverses the arrangement. Previously the absence of post-quantum exchange was the norm and its presence unusual. Now it is the other way round.

A client claiming to be a modern Chrome while offering no post-quantum exchange contradicts itself. The declared browser promises something the handshake does not contain. That mismatch needs no decryption and is visible from the very first message.

So what needs checking is not the name of the selected profile but the actual content of the handshake. A profile named after a current browser, assembled by a year-old library, produces exactly the combination that does not occur in the wild.

A side effect: the handshake no longer fits in one packet#

That extra kilobyte has an unexpected consequence.

The client message now frequently does not fit into a single segment and is split across two. This is normal behaviour for most modern traffic.

The irony is that splitting the first message across segments was for years used as a trick against primitive filters that did not reassemble streams. Today it is not a trick but the norm — and its absence has itself become the anomaly.

It is worth testing the inverse too: whether intermediate equipment reassembles such a split message. Equipment that expects a handshake in one packet may behave unpredictably on traffic that has become mainstream.

Walkthrough: what the mismatch looks like#

An observer does not need to decrypt anything. Comparing two fields from a single message is enough.

CONSISTENT CLIENT
  declared browser:   Chrome 131
  exchange groups:    X25519MLKEM768, X25519, secp256r1
  message size:       ~1,700 bytes, two segments
                      └── matches the population ✓

INCONSISTENT CLIENT
  declared browser:   Chrome 131          ← promises post-quantum exchange
  exchange groups:    X25519, secp256r1   ← but does not offer it
  message size:       ~600 bytes, one segment
                      └── no such Chrome exists ✗

The check costs the observer a single field comparison. It needs no decryption, no statistics, no accumulated history — the mismatch is visible in the connection’s first message.

That is what makes it expensive for camouflage: a cheap check gets applied at scale.

A numeric example: how the population shifted#

The ratio flipped within a single year, and with it what counts as an anomaly.

Early 2025 Late 2025
Share of post-quantum traffic 29% 52%
A client with post-quantum exchange minority majority
A client without it, claiming a modern browser unremarkable anomaly

Note that what changed was not the strength of the check but the background. The very same client that looked entirely ordinary in early 2025 stood out by the end of the year — without changing by a single byte.

Hence a general rule that reaches well beyond this case: a fingerprint expires not when it is computed, but when the population it is supposed to disappear into changes.

A fingerprint is more than the handshake#

The second common misconception is treating a matching handshake fingerprint as the end of the matter.

There are more observable layers:

Layer Solved by choosing a handshake profile?
Extension set and ordering yes
Record sizes after the handshake no
Application-protocol behaviour no
Burst shape and inter-burst pauses no
Destination address reputation no
Extra latency introduced by an intermediate hop no

A handshake-reproduction library covers the first row. The rest remain, and recent research shows classification increasingly leaning on exactly those.

Which shifts the task: copy not a browser’s handshake but the observable behaviour of a browser session as a whole — without collapsing throughput to something unusable.

Library hygiene#

A separate topic, easily lost behind architectural discussion.

Handshake-reproduction libraries are ordinary code with ordinary defects. In 2026 vulnerabilities were published in a popular library, among them a mismatch in the profiles reproducing Chrome: under certain conditions a parameter combination was chosen that real Chrome cannot choose.

A defect of that kind does not break the connection. It makes the connection recognisable — precisely what the library is deployed to prevent.

Practical conclusion: the version of your fingerprint-reproduction library is a security parameter, not a build detail. An outdated version reproduces a browser that no longer exists.

What to check#

A short list for anyone configuring camouflage:

Whether the actual handshake matches the declared browser. Verified by capture and comparison against a real browser of the current version, not by the profile’s name.

Whether post-quantum exchange is present, if the profile presents as a modern browser. Its absence is a standalone trait.

Whether the reproduction library is current. Look at published vulnerabilities, not only at the release date.

Whether the layers agree with each other. The client declared in headers must match the handshake fingerprint. A disagreement between them is a cheap check for an observer.

Summary: what is claimed, what is sent, how it looks#

What the client claims What it actually sends How it looks to an observer
a modern browser post-quantum key exchange like the majority, nothing stands out
a modern browser classical key exchange a mismatch: version and fields disagree
an outdated version the fields of that same outdated version consistent, but rare and therefore noticeable
nothing in particular the library’s own field set a category of its own, recognised immediately

The second row is the dangerous one: it appears by itself when the configuration was never touched and the population around it moved.

Conclusion#

Browser imitation remains a working approach, but it has stopped being a “pick a profile and forget” setting.

The browser population changes, and a year-old fingerprint reproduces a browser that no longer exists. The post-quantum shift is the most visible example of such a move, but it will not be the last: any mass change in browser behaviour creates the same divergence.

What follows is a practice rather than a one-off action: the fingerprint is verified against the current population, not against the one the profile was written for.

Terms#

  • Handshake fingerprint - the stable set of fields, and their order, at the start of a secure connection, by which a client library is identified.
  • Post-quantum key exchange - a key agreement algorithm resistant to a quantum adversary; it became mainstream in browsers during 2025.
  • Version mismatch - the state where a claimed client version does not match the field set that version is supposed to send.

FAQ#

Why did browser imitation stop working?#

Because the original changed. A fingerprint without post-quantum key exchange now stands out against the population instead of blending into it.

Is updating the library enough?#

Usually yes, but verify the outcome: that the claimed version matches the actual field set, rather than checking a version number in settings.

Is the fingerprint only the handshake?#

No. Post-handshake behaviour, request ordering and transport-layer parameters all add to it.

Further reading#