RFC 10015 Will Change Chrome's JA4 Fingerprint

The canonical Chrome JA4 fingerprint, the one in our own JA4 format reference and the one you have probably pasted into a WAF rule, is a countdown timer. It started running in July 2026.

Two RFCs published that month quietly changed what a conformant TLS client is allowed to say in its very first message. Neither is about bot detection. Neither mentions fingerprinting. But because JA4 is derived directly from that first message, both are about to move every browser fingerprint in your corpus.

We measured a live Chrome to find out exactly how far. Here is the number.

What the RFCs actually say

RFC 9851 puts TLS 1.2 into feature freeze. Only security fixes and tightly scoped additions from here; all post-quantum work moves to TLS 1.3 and later, exclusively.

RFC 10015, “Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2,” is the one that matters for fingerprinting. On the Standards Track, it makes three key exchange families MUST NOT for clients and servers alike:

Read the RSA row again, carefully: MUST NOT offer. Not “must not negotiate.” The violation is putting the suite in the ClientHello in the first place.

That single word is why a TLS 1.2 housekeeping RFC lands squarely on top of TLS fingerprinting.

We measured a live Chrome

Most coverage of these RFCs is aimed at server operators: nginx and Apache ship non-conformant defaults, here is your new ssl_ciphers line. Fair enough. But nobody checked the other end of the handshake, so we pointed a current Chrome at a TLS inspection endpoint and read back its own ClientHello.

Chrome 151 on macOS, August 2026:

t13d1516h2_8daaf6152771_806a8c22fdea

That prefix decodes as TLS 1.3, SNI present, 15 cipher suites, 16 extensions, ALPN h2. If it looks familiar, it should be. It is character-for-character the example in our own format reference and the shape of essentially every desktop Chrome on the internet.

Now the raw variant, which lists the cipher values instead of hashing them:

002f,0035,009c,009d,1301,1302,1303,c013,c014,
c02b,c02c,c02f,c030,cca8,cca9

Four of those fifteen are RSA key exchange:

Current Chrome is not conformant with RFC 10015. It offers four cipher suites the standard now forbids offering.

To Chrome’s credit, the FFDHE side is already clean. There is no 0033, 0039, 009e or 009f anywhere in that list. Those were dropped years ago. The RSA suites survived as the last-resort tail of the list, and they are the ones now out of spec.

”But Chrome uses TLS 1.3”

It does. Against any modern server, not one of those four suites is ever selected, and no user’s traffic is protected by RSA key exchange today. Every negotiated connection is already fine.

None of which matters, because JA4 does not observe what was negotiated. It observes what was offered. The cipher count in the readable prefix and the SHA-256 in the second section are both computed from the ClientHello’s advertised list, before the server has said a word. Those four dead suites are load-bearing inputs to a fingerprint that ten thousand WAF rules depend on.

The fingerprint after compliance

The JA4 cipher hash is the first 12 characters of the SHA-256 of the sorted, comma-separated cipher list. That is fully reproducible, so we can check our arithmetic against today’s known-good value before predicting tomorrow’s:

# Today's Chrome, should reproduce the published hash
printf '002f,0035,009c,009d,1301,1302,1303,c013,c014,c02b,c02c,c02f,c030,cca8,cca9' \
  | shasum -a 256 | cut -c1-12
# → 8daaf6152771   ✅ matches

# The same list with the four RSA suites removed
printf '1301,1302,1303,c013,c014,c02b,c02c,c02f,c030,cca8,cca9' \
  | shasum -a 256 | cut -c1-12
# → 5e2a75874763

So when Chrome ships an RFC 10015 conformant ClientHello, its fingerprint moves:

today  t13d1516h2_8daaf6152771_806a8c22fdea
after  t13d1116h2_5e2a75874763_806a8c22fdea
        └──┬──┘   └─────┬────┘  └────┬────┘
     15 → 11 ciphers  new hash    unchanged

Three things worth noting about that diff:

• The readable prefix changes, because the cipher count drops from 15 to 11. Anyone pattern-matching on the literal t13d1516h2 loses browser Chrome.
• The cipher hash changes completely. It is a hash; there is no partial match, no near miss.
• The extension hash does not move at all. Extensions and signature algorithms are untouched by this RFC, which is a small mercy and a useful diagnostic. A fingerprint that changed section two while section three held still is almost certainly this transition and not a different client.

One honest caveat on the predicted value: it assumes Chrome removes exactly those four suites and changes nothing else in the same release. If the same cleanup also drops the ageing ECDHE-CBC suites (c013, c014), the count and hash land somewhere else. The shape of the change is certain; the exact string is a forecast. Treat 5e2a75874763 as the value to watch for, not gospel.

Your JA3 rules move too, and worse. 156-157-47-53 simply falls off the end of the cipher field, and JA3 has no readable section to tell you why.

What actually breaks

Hard-coded JA4 rules. We have published guidance on pushing JA4 rules into your WAF, so we will say the uncomfortable part plainly: any rule pinned to a JA4 literal has a shelf life bounded by the next TLS stack update of the client it describes. This RFC just put a large number of those updates on the calendar at once.

Fingerprint corpora. Match a JA4 against a community database to answer “what client is this?” and every browser entry recorded before the transition becomes a miss afterwards. Not a wrong answer, an absent one. Your unknown-client rate climbs and nothing in your logs explains it.

Actor continuity. This is the subtle one. If you key a persistent identity on a TLS fingerprint, then a browser update rewrites that key, and one returning visitor becomes two strangers. Our composite actor model is built for exactly this. It keys on the strongest available tier and treats JA4 as the coarse network layer, so a JS-capable client keeps its identity through a TLS stack change. But non-JS clients, where JA4 is the only tier available, are genuinely exposed. Worth auditing before the transition rather than after.

Detection thresholds tuned on cipher counts. “Fewer than 10 ciphers is suspicious for a browser” was a reasonable heuristic when browsers offered 15. At 11, the margin narrows considerably.

The flip side: frozen snapshots become the tell

Now the good part, and it is genuinely good.

TLS fingerprinting works on an asymmetry we have written about before: you cannot spoof a ClientHello by editing a header, because the handshake is a property of the compiled TLS stack. The standard countermeasure is curl-impersonate and its descendants, which replay a byte-exact copy of a real Chrome’s ClientHello and inherit its fingerprint.

That copy is a snapshot of a specific Chrome version, and snapshots do not update themselves.

Real Chrome will comply with RFC 10015 on Google’s release cadence. Every frozen impersonation profile built before that keeps offering four RSA key exchange suites forever, until somebody rebuilds and reships it. So does every Go crypto/tls fork, every scraper pinned to an older OpenSSL, every hand-rolled handshake in a proxy farm.

The result is a new, cheap contradiction to look for: a client offering deprecated key exchange while claiming to be a current browser. Before this RFC, offering RSA kex was simply what browsers did, so it carried zero signal. After it, the same bytes say this stack has not been updated since mid-2026, in a way that no user-agent string can paper over. Compliance becomes a freshness proof, and impersonation tooling is structurally last to earn it.

For a while, the fakes will be the only ones still doing the old thing.

What to do about it

1. Log JA4_r, not just JA4. The raw variant lists cipher values in the clear, so you can grep for 002f, 0035, 009c, 009d and see conformance directly. You cannot recover a cipher list from a hash, so build the raw corpus now, while the pre-transition baseline still exists to compare against.
2. Stop pinning rules to JA4 literals. Treat a JA4 as a versioned observation of a software build, not a permanent name for a client: rules that describe properties, like low cipher count, no ALPN or missing extensions, survive this transition; rules that quote a hash do not.
3. Audit anything keyed on JA4 alone. Especially non-JS traffic, where there is no second tier to fall back on.
4. Add the contradiction check. Deprecated key exchange plus a current-browser user-agent is a signal you can start scoring the moment mainstream browsers comply.
5. Re-derive, don’t guess. The hash is reproducible in one line of shell. When a browser ships the change, confirm the new value from a live capture rather than trusting anyone’s forecast, including ours.

The deeper point is that a TLS fingerprint is not an identity. It is a description of a software version, and software versions move. That is exactly what makes JA4 valuable, since it tracks the real client rather than what the client claims, and exactly why it needs maintenance. Any detection system treating fingerprints as permanent facts was always going to break. RFC 10015 just picked the date.

WebDecoy computes spec-compliant JA4 from the raw ClientHello and correlates it into persistent actors across three fingerprint tiers, so a browser’s TLS stack changing underneath you is a logged transition rather than a silent gap. If you want the full mechanics, start with the JA4 fingerprinting guide or decode your own fingerprint in the format reference.