TLS Fingerprinting

TLS fingerprinting identifies a client by the precise pattern of cipher suites, extensions, and elliptic curves it advertises in its TLS handshake. The most common implementation is JA3 (and its successor JA4), which hashes the TLS Client Hello fields into a short fingerprint. Real browsers — Chrome, Firefox, Safari — produce distinctive, stable fingerprints; Python's `requests`, Go's `net/http`, and Node's `https` libraries produce equally distinctive but very different fingerprints that anti-bot systems easily flag as automation. The defense against TLS fingerprinting is to make your client's handshake match a real browser's. Libraries like curl-impersonate (C), tls-client (Go), curl_cffi (Python), and undici with custom TLS settings (Node) ship handshake configurations that match Chrome or Firefox precisely. Once your TLS fingerprint matches a browser, the next layers of detection (HTTP/2 frame ordering, header order, JavaScript challenges) come into play — TLS fingerprinting is just the first probe. For AI builders, TLS fingerprinting is one of the lowest-level signals you have to think about and one of the easiest to fix. Most modern scraping APIs and managed browser infrastructure providers handle it transparently. If you are building scraping in-house and getting silently blocked despite correct user agents, TLS fingerprint mismatch is the most common root cause.