Chrome profiles missing ML-DSA signature algorithms — `chrome142` ceiling vs Chrome 151 stable

[jackc625]

The newest Chrome TLS profile is chrome142, on both 0.13.0 and the current 0.14.3, and chrome.rs on master tops out at chrome_142. Chrome stable is currently 151.

The interesting part is that the wire-level gap is much smaller than that version distance suggests — I measured it rather than assuming, and it comes down to three signature algorithms.

Measurement

Real Chrome 150 (Playwright channel: "chrome", so a genuine Chrome binary, not bundled Chromium) and impit chrome142, both against https://tls.peet.ws/api/all:

Real Chrome 150

ja4   t13d1516h2_8daaf6152771_806a8c22fdea
ja4_r t13d1516h2_002f,0035,009c,009d,1301,1302,1303,c013,c014,c02b,c02c,c02f,c030,cca8,cca9_0005,000a,000b,000d,0012,0017,001b,0023,002b,002d,0033,44cd,fe0d,ff01_0904,0905,0906,0403,0804,0401,0503,0805,0501,0806,0601

impit chrome142 (0.13.0; 0.14.3 produces the same ja4)

ja4   t13d1516h2_8daaf6152771_d8a2da3f94cd
ja4_r t13d1516h2_002f,0035,009c,009d,1301,1302,1303,c013,c014,c02b,c02c,c02f,c030,cca8,cca9_0005,000a,000b,000d,0012,0017,001b,0023,002b,002d,0033,44cd,fe0d,ff01_0403,0804,0401,0503,0805,0501,0806,0601

Component by component:

JA4_r component	impit chrome142 vs real Chrome 150
ciphers (15)	identical
extensions (14, incl. 44cd ALPS, fe0d ECH)	identical
signature algorithms	real Chrome has 0904,0905,0906 at the head; impit has neither

0x0904 / 0x0905 / 0x0906 are mldsa44 / mldsa65 / mldsa87 from draft-ietf-tls-mldsa. Chrome now advertises ML-DSA in signature_algorithms; no impit profile does.

Because JA4_c hashes the sorted extension list plus the signature-algorithm list, those three codepoints are the entire reason chrome142 produces a different JA4 from current Chrome. Ciphers and extensions already match exactly.

Reproduction

import { Impit } from "impit";

const client = new Impit({ browser: "chrome142" });
const res = await client.fetch("https://tls.peet.ws/api/all");
console.log((await res.json()).tls.ja4_r);

Compare against a real Chrome by navigating the same browser build to https://tls.peet.ws/api/all.

Questions

1. Is a Chrome profile refresh planned — perhaps as part of chore(deps): update dependencies and improve fingerprinting logic #424, which already touches chrome.rs?
2. Given the delta is this narrow, would a PR be welcome for either of:
   • adding mldsa44/65/87 to the existing chrome142 signature-algorithm list, or
   • a new chrome15x profile captured from a current Chrome?

Happy to do the capture work and open the PR if you'd point me at how you'd prefer profiles to be sourced and verified — I did not want to guess at your methodology and submit a profile that matches no real browser.

Environment

• impit 0.13.0 (also verified 0.14.3)
• Node 22, Windows x64
• Reference browser: Google Chrome 150 (stable channel; Chrome stable is 151 at time of writing)
• Oracle: tls.peet.ws/api/all

[barjin]

Thank you for your interest in this project.

Contributions are always welcome. Feel free to open a PR adding the chrome151 fingerprint. I don't see a point in editing the existing chrome144 fingerprint, as that might be a breaking change for some current users.

Cheers!

[jackc625]

Thanks! Happy to take this on.

One wrinkle from scoping it: FingerprintSignatureAlgorithm in apify/rustls (rustls/src/crypto/emulation/mod.rs) has no ML-DSA variants, so no profile can emit 0904/0905/0906 today. The SignatureScheme::ML_DSA_44/65/87 constants already exist in that fork's enums.rs; they just aren't wired into the emulation layer.

So this is two PRs. Happy to do both. Would you rather see the apify/rustls one land first, or both open together?