Skip to content
All fingerprint checksTLS & the network layer

TLS cipher list matches the claimed engine

Check id tls-cipher-suite-vs-engine

What an ordinary browser yields

A user agent naming a Chromium engine, and a ClientHello offering Chromium's cipher list. For Gecko and WebKit the check declines instead of guessing — the corpus holds too few of those machines to support a baseline, and inventing one from four samples is exactly how a reference table starts making false accusations.

What a detector infers

Your browser announces which engine it is twice, through channels that cannot reach each other. navigator.userAgent is a string any page can read and almost anything can rewrite. The TLS ClientHello is written by the network stack before a single line of page script exists — no user-agent override, no extension and no CDP command can touch it. The list of cipher suites your browser offered is therefore an independent account of the same fact, and the two either agree or they do not. The comparison is made on the JA4 fingerprint's middle component, which hashes that cipher list, and the choice of that component is measured rather than assumed: across the donated corpus every one of 78 Chromium-family machines emitted the same cipher hash — Chrome 145 through 150, Chromium, Brave and headless Chrome alike — while over the same rows the JA4 prefix took three values and the extension hash took four. The cipher list is compiled into BoringSSL and does not move between releases; extension counts move with feature flags, enterprise policy and middleboxes, so a check built on those would fire at ordinary browsers. This is deliberately an ENGINE test and not a brand test: Chrome, Edge, Brave and Opera share one TLS stack and are indistinguishable here, which is correct rather than a shortcoming. The only claim under test is that a browser calling itself Chromium speaks TLS like Chromium.

How to resolve it

A cipher list that disagrees with the claimed engine has two ordinary causes, and it is worth separating them before treating this as a fault. If you are on a corporate or otherwise managed network, a TLS-inspecting appliance has terminated the connection and re-originated it with its own ClientHello; the finding is then about your network rather than your browser, and there is nothing in the browser to change. Otherwise the user agent does not describe the stack that made the connection — an HTTP client impersonating a browser, or a real browser whose user agent was rewritten while its TLS stack was not. The resolution is the one that runs through this entire audit: change the engine, not the label. A user agent is one line of text; the cipher list is a property of the TLS library that was compiled in.

What is a JA3 / JA4 TLS fingerprint?

Other checks in TLS & the network layer

Who builds this test

Clearcote is a browser built for fingerprint coherence

It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.

This audit takes no position on how Clearcote scores on TLS & the network layer checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.

See the other checks in TLS & the network layer — the family tls-cipher-suite-vs-engine belongs to.