What is TLS fingerprinting?

TLS fingerprinting identifies a client from how it opens an encrypted connection. Before any HTTP request exists, your client sends a ClientHello listing the TLS versions, cipher suites, extensions, elliptic curves and signature algorithms it supports. The exact contents and, crucially, the exact order of those lists vary between implementations. Hashing them produces a fingerprint, commonly a JA3 or the newer JA4.

The reason this matters more than most detection methods: it happens below HTTP entirely, so nothing you set in your request headers affects it.

Why it is so effective against scrapers

Chrome produces one handshake. Firefox produces another. Python's requests on OpenSSL produces a third that resembles neither. Go's crypto/tls produces a fourth. These are properties of the TLS library, not of anything you configure.

So a request whose user agent says Chrome 131 while its handshake says OpenSSL is self-contradicting at the first packet. A site does not need to analyse your behaviour, examine your headers or run any JavaScript to know something is wrong. It costs one lookup against a table of known fingerprints.

This is why the most common first attempt at bypassing a block, changing the user agent, so often changes nothing. It makes the contradiction sharper.

What a fingerprint is built from

• Cipher suites, in the order offered. Browsers offer a specific set in a specific priority.
• Extensions, again in order. Chrome deliberately randomises some extension ordering, which is itself a recognisable behaviour.
• Supported groups and signature algorithms, the elliptic curves and hashing schemes on offer.
• ALPN, which protocols the client will negotiate, such as HTTP/2.

HTTP/2 adds a parallel signal. The settings frame a client sends on connection, its window size and header table size, differs by implementation in the same way, giving a second fingerprint immediately after the first.

What actually changes it

Only the TLS layer itself. That means one of:

• A real browser, which produces a genuine browser handshake because it is one.
• A client built to imitate a specific browser's handshake, such as curl-impersonate or a library using a modified TLS stack.
• A service that terminates TLS with a browser-shaped handshake on your behalf.

Setting headers, rotating user agents, adding stealth plugins to a headless browser: none of these touch the handshake.

Where Zenrows fits

TLS is one of the layers Adaptive Stealth Mode keeps consistent with the rest of the request. The handshake, the header set and the fingerprint are selected together for the target site, so the identity presented at the TLS layer matches the one presented at every layer above it. Maintaining that by hand means tracking browser releases as their handshakes change, which is the recurring cost this removes.