An extra TLS extension (4832, server padding) changes the JA4 fingerprint
Default Chrome for Testing adds TLS extension 4832 (0x12E0) to every ClientHello: BoringSSL's experimental request for server-side handshake padding, sent with a two-byte payload of 0000. Nothing else in the handshake changes, so the extension count in JA4 goes from 17 to 18: t13d1518h2_8daaf6152771_4980c97edce0 instead of Google Chrome's t13d1517h2_8daaf6152771_cb7bf5808d99 (ja3n a3a3161a080b73bda9cc285fb367fcc0 instead of bd4930bd9b000ee684830e44bab76fdf). Open https://tls.peet.ws/api/all and run the first two checks there; run the third on https://tls.browserleaks.com/json. HTTP/2 settings, window update and priority are identical.
on tls.peet.ws/api/all: JSON.parse(document.querySelector('pre').textContent).tls.extensions.some((e) => e.name === 'Unknown extension 4832')false→ trueon tls.browserleaks.com/json: JSON.parse(document.querySelector('pre').textContent).ja4"t13d1517h2_8daaf6152771_cb7bf5808d99"→ "t13d1518h2_8daaf6152771_4980c97edce0"
Why it matters: JA4 is the most widely logged TLS client fingerprint, and a capture from default CfT is not a Google Chrome fingerprint: no Chrome 154 sends extension 4832 unless a field trial switches it on. The testing config's PqcBandwidthExperiment study enables AddTLSServerHandshakePadding with 0 bytes. Google Chrome 154 with only that feature enabled sends the identical ClientHello (measured), and CfT with --disable-field-trial-config sends Chrome's.
- Testing config: PqcBandwidthExperiment enables AddTLSServerHandshakePadding, 0 bytes
- Feature AddTLSServerHandshakePadding (disabled by default)
- RequestServerPadding: only when the feature is on
- The TLS connect job asks BoringSSL for server padding
- BoringSSL at 154 (DEPS boringssl_revision): TLSEXT_TYPE_server_padding 4832
- Why CfT applies the testing config: ShouldUseFieldTrialTestingConfig (on unless --disable-field-trial-config in non-Chrome-branded builds)