TLS ClientHello doesn't match Mozilla's official Windows builds while the default persona is Windows

Summary

Camoufox's TLS ClientHello does not match the one produced by Mozilla's official Firefox builds for Windows, while navigator.userAgent, navigator.oscpu, navigator.platform and navigator.appVersion all present a Windows persona by default. Since TLS is inspected before any JavaScript runs, this is observable by anti-bot vendors that fingerprint the handshake, and it is a contradiction the browser itself introduces.

This is the same class of problem discussed in #605, one layer lower: the concern there was that hiding navigator.webdriver would manufacture a tell rather than remove one. Here the persona and the handshake disagree by default.

Measurements

Camoufox 0.5.6, browser 152.0.4-beta.30, measured via tls.browserleaks.com/json:

	Camoufox	Stock Firefox 155, Windows 11
JA3	6447ab086255d194909d4013b1a89e87	32daeeceb3400621714e983e136c78f0
JA4	t13d1617h2_86a278354501_3cbfd9057e0d	t13d1611h2_1711a4c0508c_86ae21f8795b
HTTP/2 (Akamai)	1:65536;2:0;4:131072;5:16384|12517377|0|m,p,a,s	2:0|10485760|0|m,p,a,s
Extensions	17 — incl. 28 record_size_limit, 27 compress_certificate, 65037 ECH, 34 delegated_credentials, 65281	11 — none of those; signals renegotiation via cipher 255 (SCSV)
Groups	4588 (X25519MLKEM768), 29,23,24,25,256,257	29,23,24,25

Full ja3_text / ja4_r for both available on request.

Why this is not version drift

Public JA4 catalogues show the cipher-list hash is stable per platform across Firefox versions, while only the extension count moves:

• Firefox / Windows: 1711a4c0508c appears with t13d1609h2, t13d1610h2, t13d1611h2
• Firefox / Linux & Android: 86a278354501 appears with t13d1612h2 … t13d1615h2

Camoufox emits 86a278354501 — the non-Windows family — while defaulting to a Windows persona. A 152 → 155 gap would explain a different extension count, but not a different cipher-list hash.

Why this is not the host OS

The handshake is byte-identical on a Windows 11 host and in a Debian container (same Camoufox version and browser build, separate one-off profiles, different networks). So this follows the shipped build, not the machine it runs on.

Questions

1. Is the cipher-suite list a deliberate build choice, or a side effect of how NSS is configured when building Camoufox?
2. Would it be feasible for the build to match Mozilla's official desktop builds, so the handshake is consistent with the default Windows persona?
3. If not, is there any supported way to influence it — or would you consider documenting this as a known limitation, so users can factor it into their threat model?

Not asking for a TLS-spoofing feature; the ask is consistency between the persona Camoufox presents and the handshake it sends.

Environment

• Camoufox 0.5.6, browser 152.0.4-beta.30
• Hosts: Windows 11; Debian container (VINTED_HEADLESS=virtual, built-in Xvfb)
• Default os="windows" persona, pinned fingerprint preset