UA claims a GREASEing-engine browser (Chromium/Safari) but the TLS ClientHello has no GREASE
net.tls_grease_vs_ua · convicts
What it catches
RFC 8701: Chromium and Safari/WebKit GREASE their ClientHello; a scripted OpenSSL/Go TLS stack does not. v0.74.31 FP FIX (GROUNDED on real geckodriver Firefox 152 + Mullvad 140 + Playwright Firefox): the original 'every current browser GREASEs' premise is FALSE — GECKO/FIREFOX does NOT GREASE TLS by default (security.tls.grease_probability=0). All three real Firefox captures send a GREASE-free ClientHello while every Chromium capture GREASEs (a clean engine split), so emitting tls_no_grease on a Firefox UA convicted EVERY real Firefox (a coherence FP on ~all Firefox users). Fixed in the edge: tls_no_grease is now gated by uaGreasesTLS (Chromium/Safari, NOT Firefox). No coverage lost — a non-browser stack faking a Firefox UA is still caught by its JA4 engine mismatch (net.tls_vs_ua_browser). NB: the QUIC analog net.quic_grease_vs_ua still emits on Firefox UAs and additionally fired on a real Brave (Chromium that DOES GREASE QUIC) in-container — a separate, murkier QUIC-capture issue flagged for investigation, not fixed here.
Signals it reads
network.tls_no_grease
How it fires
present
Evaders it caught 13
Bypassed by 10
Frontier evaders that reach the detector uncaught (scored only suspicious, defeating every convicting tell) — this check is not one that stops them. The red-team frontier this detection still has to convict.