TLS Fingerprinting
AdvancedIdentifying the software behind a connection from how it performs its TLS handshake — the technique (JA3, JA4) that catches scrapers before a page even loads.
In depth
TLS fingerprinting identifies clients by the shape of their encrypted-connection handshake. When any client opens an HTTPS connection, its ClientHello message lists supported cipher suites, extensions, curves, and their exact ordering. Those choices are baked into the TLS library the software was built with — and they betray what the software really is, regardless of what its headers claim.
JA3 and its successors
The JA3 method standardized this: concatenate the handshake's parameters and hash them into a compact fingerprint. Defenders compare the hash against known populations — real Chrome produces one family of fingerprints, Firefox another, Python's requests library something else entirely. Newer schemes like JA4 extend the idea with more robust, ordering-aware signatures. The killer application: a scraper sending a perfect Chrome user agent from Python is exposed instantly, because its handshake says OpenSSL-via-Python, not Chrome's BoringSSL.
Why it's hard to fake
- It happens below your code: the handshake is written by the TLS library before your application logic runs; you can't just set a header.
- Workarounds exist but age fast: specialized libraries (curl-impersonate, tls-client and similar) replicate browser handshakes, but must chase every browser release.
- The robust answer is a real browser: automation driving actual Chrome or an antidetect browser produces a genuine browser handshake by construction.
The layer people forget
Rotating IPs and forging headers does nothing here — TLS fingerprints live in a different layer. If a protected site blocks your plain HTTP-library scraper on the first request, this is very likely why.
Examples
- A WAF blocks a request whose user agent claims Chrome but whose JA3 hash matches Python's requests library.
- A bot developer switches to a TLS-impersonation library so handshakes match real Chrome, and block rates fall.
- A defender clusters an attack's traffic across thousands of IPs by its single shared TLS fingerprint.
Common use cases
FAQs
A hash of a client's TLS ClientHello parameters — TLS version, cipher suites, extensions, curves, and their order. It identifies the underlying TLS library and thus the real client software, independent of any headers the client sends.
Yes, with effort: impersonation libraries replicate real browsers' handshakes, and driving an actual browser produces genuine fingerprints naturally. Plain HTTP libraries with spoofed headers fail against any defender that checks TLS.
No — the handshake is generated by your client software and passes through the proxy untouched. IP rotation and TLS fingerprinting are orthogonal layers; serious anti-bot systems check both, so you must handle both.