TLS fingerprinting: identifying a client by its handshake

An HTTPS connection begins with the client's ClientHello, defined in the TLS 1.3 standard (RFC 8446). It lists the TLS versions the client speaks, the cipher suites it accepts, the extensions it supports, the key-exchange groups and signature algorithms it prefers. The standard lets each client choose those lists, and each TLS library chooses differently. Chrome's BoringSSL, Firefox's NSS and a curl built on OpenSSL send recognisably different hellos.

How TLS fingerprinting works

A server, a CDN or a firewall reads the ClientHello as it arrives and reduces it to a short string. The two common formats are JA3, an MD5 of five fields in the order sent, published by Salesforce in 2017, and JA4, which sorts the lists first so that Chrome's per-connection shuffling does not change the result. The fingerprint is then looked up: this hash is Chrome 153, that one is a Go HTTP client, a third belongs to a known piece of malware.

None of this needs the page. It happens before the first byte of HTML, it ignores cookies, and no browser extension can see or change it.

How it works: Its own Chromium

What it catches

A TLS fingerprint rarely separates two people. Everyone on the same Chrome version sends the same set of ciphers and extensions. What it catches is a client lying about what it is.

The classic case is a script that copies a browser's User-Agent header onto an HTTP library. The headers say Chrome; the handshake says Python. A server that compares the two layers sees the contradiction on the first request. The same check catches a browser that claims one Chrome major in its User-Agent and client hints while its handshake belongs to another. Between Google Chrome 152 and 153 on the same machine we measured a change in the extension count, 17 against 18, so the version shows in the handshake as well.

Above TLS there is HTTP/2. The SETTINGS frame a client sends when the connection opens, its values and their order, and the order of request headers are a second fingerprint of the same kind, read by bot-management services alongside the handshake.

Why we do not spoof it

Many anti-detect browsers advertise a per-profile TLS or JA3 setting. We decided against one. Every real Chrome of a version sends the same hello, so giving a profile a different one does not separate it from other profiles: it makes it the only Chrome on the internet with that handshake. And a handshake chosen per profile drifts from the version the profile claims the moment Chrome updates.

So we measured instead. We pointed our engine and Google's branded Chrome at a bare TCP listener on the same machine, parsed the first record of each, and compared every field: legacy version, cipher suites, extension set and count, supported groups, supported versions, signature algorithms and ALPN. Zero fields differed once Chrome's own shuffle and random GREASE values were set aside. The HTTP/2 SETTINGS frame, header order and ALPN matched too. Against Google's Chrome for Testing 153 the JA4 values were byte-identical.

How Mosaic handles it

Mosaic's engine, Tesseract Chrome, is Chromium built from stock source, so its TLS and HTTP/2 come from Chrome's own network stack, unmodified. A proxy does not change them: with HTTPS, the proxy tunnels the browser's handshake to the site. The patches change the values a page reads, in C++, and leave the connection alone. What they do change is listed on the engine page, and the other layers detectors compare against the handshake are in how sites detect anti-detect browsers.