Chrome is missing the trust_anchors ClientHello extension

[konohog114]

HelloChrome_Auto currently points to HelloChrome_133. That profile is now behind current Chrome in at least one visible ClientHello detail: Chrome sends the TLS trust_anchors extension (0xca34, decimal 51764) by default, while uTLS does not.

I captured ClientHello messages locally on Windows and saw this:

Client	trust_anchors	ClientHello TLS record size
Chrome for Testing 140.0.7339.207	no	1818 bytes
Chrome for Testing 141.0.7390.37	yes, len 2	1792 bytes
Chrome for Testing 141.0.7390.55	yes, len 2	1792 bytes
Chrome for Testing 149.0.7827.54	yes, len 2	1792 bytes
Chrome 149.0.7827.54 with --disable-features=TLSTrustAnchorIDs	no	1786 bytes
uTLS HelloChrome_133 / current HelloChrome_Auto	no	1786 bytes

So, from these captures, Chrome appears to have enabled this by default starting with Chrome 141. The extension code existed earlier in Chromium/BoringSSL, but the wire behavior changed at the Chrome 141 boundary in the tested stable builds.

The missing extension is small but fingerprint-visible. The wire encoding is:

ca 34 00 02 00 00

That is 6 bytes total: extension type 0xca34, extension length 2, and an empty vector 0000.

The issue is Chrome ClientHello parity: the extension set, JA3-style inputs, and total ClientHello size differ from modern Chrome.

BoringSSL defines the extension as TLSEXT_TYPE_trust_anchors 0xca34 and documents that an empty value still sends the extension in ClientHello. Chromium exposes this through TLSTrustAnchorIDs; disabling that feature in Chrome 149 removes the extension from the captured ClientHello.

[konohog114]

links for this issue:

• Chromium CL that appears to explain the Chrome 140 -> 141 wire behavior change:
  https://chromium.googlesource.com/chromium/src/+/9dcef31f77214e3a60b33e87be5249dd08408c40
  Title: Send empty trust anchor extension when there is nothing from DNS
  Commit position: refs/heads/main@{#1500868}

• Sends empty trust_anchors when there is no DNS hint:
  https://chromium.googlesource.com/chromium/src/+/9dcef31f77214e3a60b33e87be5249dd08408c40/net/socket/ssl_connect_job.cc#397
  https://chromium.googlesource.com/chromium/src/+/9dcef31f77214e3a60b33e87be5249dd08408c40/net/socket/ssl_connect_job.cc#400

• Chromium docs for empty vector behavior:
  https://chromium.googlesource.com/chromium/src/+/9dcef31f77214e3a60b33e87be5249dd08408c40/net/ssl/ssl_config.h#186

• Chromium passes trust_anchor_ids to BoringSSL:
  https://chromium.googlesource.com/chromium/src/+/9dcef31f77214e3a60b33e87be5249dd08408c40/net/socket/ssl_client_socket_impl.cc#838

• BoringSSL commit adding the extension:
  https://boringssl.googlesource.com/boringssl/+/7e529d2b3

• BoringSSL extension codepoint 0xca34:
  https://boringssl.googlesource.com/boringssl/+/7e529d2b3/include/openssl/tls1.h#138

• BoringSSL docs: empty ids_len == 0 still sends the extension in ClientHello:
  https://boringssl.googlesource.com/boringssl/+/7e529d2b3/include/openssl/ssl.h#3043

• BoringSSL ClientHello extension implementation:
  https://boringssl.googlesource.com/boringssl/+/7e529d2b3/ssl/extensions.cc#2563
  https://boringssl.googlesource.com/boringssl/+/7e529d2b3/ssl/extensions.cc#2571

• Chromium field trial config for TLSTrustAnchorIDs:
  https://chromium.googlesource.com/chromium/src/+/7bcaf312a1e5b2ec848e6b71afb3ffea7ae5c9e1/testing/variations/fieldtrial_testing_config.json#23999
  https://chromium.googlesource.com/chromium/src/+/7bcaf312a1e5b2ec848e6b71afb3ffea7ae5c9e1/testing/variations/fieldtrial_testing_config.json#24010

From my local captures, default Chrome ClientHello did not include trust_anchors in Chrome 140.0.7339.207, but did include it in Chrome 141.0.7390.37 and later.

[konohog114]

I also compared JA3 and JA4 from the captured ClientHello messages.

The useful part is that JA4 removes Chrome's shuffled extension-order noise, but the missing trust_anchors extension still changes the JA4 fingerprint.

ClientHello	trust_anchors	JA3 MD5	JA4
Chrome 141.0.7390.37	yes	e688c62503d572876d640ee678559e0a	t13d1517h2_8daaf6152771_dcad5a053991
Chrome 149.0.7827.54	yes	131c03754f7029444df9f53e8161ba59	t13d1517h2_8daaf6152771_dcad5a053991
Chrome Dev 151.0.7872.0	yes	6a27b931965bf4e2edf8e8a8fee4e974	t13d1517h2_8daaf6152771_cb7bf5808d99
Chrome 149.0.7827.54 with --disable-features=TLSTrustAnchorIDs	no	6c158400e7428ea227eca2ef1a790a73	t13d1516h2_8daaf6152771_d8a2da3f94cd
uTLS HelloChrome_133 / current HelloChrome_Auto	no	4d41f48348ac47eb73d3cc75103ee854	t13d1516h2_8daaf6152771_d8a2da3f94cd

So the current uTLS Chrome parrot has the same standard JA4 as Chrome with TLSTrustAnchorIDs disabled, not default Chrome.

Readable JA4 makes the difference explicit:

Chrome 149 default:
t13d1517h2_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,ca34,fe0d,ff01_0403,0804,0401,0503,0805,0501,0806,0601

uTLS HelloChrome_133:
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

Chrome Dev 151.0.7872.0:
t13d1517h2_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,ca34,fe0d,ff01_0904,0905,0906,0403,0804,0401,0503,0805,0501,0806,0601

• Chrome default: t13d1517h2... because it has 17 non-GREASE extensions.
• uTLS / Chrome with the feature disabled: t13d1516h2... because ca34 is missing.
• The cipher hash is the same: 8daaf6152771.
• The extension/signature hash changes from dcad5a053991 to d8a2da3f94cd.
• Chrome Dev 151.0.7872.0 additionally advertises ML-DSA signature algorithms 0904, 0905, 0906, so its JA4 extension/signature hash is cb7bf5808d99.