TLS fingerprinting (JA3)
JA3 is a method of fingerprinting TLS client implementations based on the specific parameters they send during the TLS handshake. Different clients (browsers, libraries, curl) have distinguishable JA3 signatures.
Definition
JA3 is a method of fingerprinting TLS client implementations by hashing specific parameters sent during the TLS ClientHello handshake: the TLS version, the list of cipher suites offered, the list of extensions, the elliptic curves, and the EC point formats. The hash of these parameters is the JA3 signature.
A real Chrome browser sends a specific JA3 signature; a real
Firefox sends a different one; curl sends its own; python- requests sends yet another. Anti-bot systems use these
signatures to distinguish real browser traffic from automation.
Developed at Salesforce (original paper ~2017), JA3 is now one of the most common inputs to commercial anti-bot scoring.
Why JA3 matters for AI scraping
Sending realistic HTTP headers (User-Agent claiming to be
Chrome, plausible Accept-Language, etc.) doesn't help if your
TLS stack signature exposes the client as python-requests.
Anti-bot systems that check JA3 will classify the traffic as
automated regardless of header choices.
For AI data collection, this means:
- Any Python stdlib or requests-based scraping has a distinctive JA3 that targets can identify
- Headless browsers (Chrome via Playwright) inherit the real Chrome JA3 and are safer on this axis
- Fingerprint-impersonating libraries like
curl-cffiandtls-clientexplicitly replicate Chrome's JA3
What the proxy layer contributes here
The proxy layer is orthogonal to JA3. A residential proxy doesn't change your client's TLS fingerprint. The two pieces — network origin (proxy) and client fingerprint (TLS) — are both part of anti-bot posture and both matter, but they're independent.
Related
Ship on a proxy network you can actually call your ops team about
Real ASNs, real edge capacity, and an engineer who answers your Slack the first time.