TLS Fingerprinting

This page explains everything you need to know about TLS when making requests based modules.

Why Antibots Use TLS Fingerprinting

TLS fingerprinting is a powerful technique employed by antibot systems to distinguish between legitimate browser traffic and automated requests. When a client initiates a TLS handshake, it reveals specific characteristics about the underlying software making the connection.

Standard HTTP request libraries (like Python's requests, Node.js's axios, or Go's net/http) have distinctly different TLS fingerprints compared to real web browsers. These libraries typically:

• Use different cipher suite preferences

• Support different TLS extensions

• Order TLS extensions in predictable patterns

• Have library-specific SSL/TLS implementation details

Since automated bots and scrapers commonly rely on these standard libraries, antibot systems can easily identify and block requests that don't match expected browser fingerprints. This creates an effective first line of defense against automated traffic, as legitimate users virtually never use request libraries directly.

Solution: Browser-Matching TLS Clients

To bypass TLS fingerprinting, you need HTTP clients that can mimic real browser TLS behavior. Two excellent options are available:

tls-client

Repository: https://github.com/bogdanfinn/tls-client

A Go-based HTTP client that can impersonate various browsers' TLS fingerprints with high fidelity. Multiple wrappers for Python and Node.js are available and listed here: https://bogdanfinn.gitbook.io/open-source-oasis/community-projects

azuretls-client

Repository: https://github.com/Noooste/azuretls-client

A Go HTTP client designed to replicate browser TLS characteristics and bypass fingerprinting detection.

Recommended Configuration

Use the latest Chrome profile your client ships (for example Chrome133 or newer), and enable random TLS extension ordering:

• Profile: the most recent ChromeNNN profile available in your library

• Random TLS extension order: Enabled

• HTTP/3 disabled: most proxies don't support it yet, so force HTTP/2 (the version numbers in profile names like Chrome133 are illustrative; use the latest your library ships)

Match the profile to the Chrome version in your User-Agent as closely as the library allows. Chrome's TLS ClientHello doesn't change on every release, so a slightly older profile is acceptable when your library hasn't shipped the newest one yet, see User Agents for the current stable version and the fallback rule.

This configuration ensures your requests closely mimic genuine Chrome browser traffic.

By using these specialized clients with proper configuration, you can effectively bypass TLS fingerprinting while maintaining the convenience of programmatic HTTP requests. Get in touch: discord.gg/akamai