- Joined
- 31.10.19
- Messages
- 1,691
- Reaction score
- 5,602
- Points
- 113
Imagine this scenario: you carefully prepared for multi-accounting - set up the environment, assigned a unique residential proxy to each stream, confident in the cleanliness of your IP addresses. But after starting, all your accounts get banned one after another, even though each stream used its own unique IP address. As they say - a stalemate situation, what could be the reason? The reason you lost your profiles may be TLS fingerprinting. This isn’t some hidden technology of ancient civilizations, but a modern technique that works deeper than the IP level and can identify devices and sessions by the distinctive fingerprint of a TLS connection. In other words, if all your requests share the same TLS fingerprint, even the best proxies won’t save you from blocks on platforms that use these fingerprints.
What TLS fingerprinting is and how it works
TLS (Transport Layer Security) is the cryptographic protocol that secures HTTPS connections between client and server. We’re interested in the very first data exchange - the TLS handshake. During this virtual exchange, the client sends a ClientHello message with a set of parameters for negotiating encryption. These parameters can largely give away who is connecting to the server. The set of data contained in ClientHello forms a unique TLS fingerprint - one of the digital identifiers of the client. In the screenshot below I provided an example of such a fingerprint - a real TLS handshake capture I intercepted with Wireshark on my local device.
The problem (and for some it will be a real problem) is that each browser, library, or OS implements TLS in its own way, so the parameter set becomes unique. A TLS fingerprint will always remain constant for a specific client regardless of its IP address or proxy. It may change slightly if the set of fonts or extensions changes, but in most cases it will be identical. What forms a TLS fingerprint:
- TLS version. Standard Chrome supports TLS 1.3, while Python’s requests library might use 1.2 or also 1.3 like Chrome, etc.
- Cipher suites. Not the fonts you type with - these are the encryption algorithms. Each browser has a roughly similar set, but differences exist - Firefox has about 15 ciphers, Chrome about 17; scripts (python requests, curl) have a shorter list typical of OpenSSL and the actual supported algorithms may differ.
- List of TLS extensions. These are additional protocol options (SNI, ALPN, OCSP, etc) that handle various application tasks. The set and number of extensions depend on the browser and differ between them - this creates part of the distinction.
- Supported groups (curves). This is the mathematical language used for cryptography. Each browser has its own list of supported methods.
- Signature algorithms. Preferred algorithms for digital signatures within TLS (priorities differ between clients). This is a list of standards your browser can verify. Chrome checks by some algorithms, Safari by others.
An analogy: if you put garlic in a pan first and add meat only five minutes before serving, the taste will differ from the classic recipe where meat is cooked first and garlic added at the end - order matters. The same goes here.
JA3 - what’s the "three" about in that old PC game? If you remember the Jagged Alliance game, you might think the author forgot his meds, but no - JA3 has nothing to do with gaming. It’s about TLS fingerprints and a technique for representing them. JA3 is a 32-character hash computed from the combination of parameters listed above. It’s convenient to store and compare. That hash is our fingerprint. Each unique combination of parameters yields its own JA3 hash; even minimal differences produce different hashes - Chrome 120 on Windows 11 and Firefox 121 on the same device will produce different fingerprints. You can discover your JA3 hash using special services (tls.peet.ws) or via Wireshark.
Note: Wireshark is traffic analysis (sniffer) software that lets you see data passing through your computer in real time.
Summary: TLS fingerprinting can reliably distinguish one client from another by analyzing only the network parameters of the encrypted connection. Neither changing IP nor spoofing User-Agent will help - the handwriting of your TLS handshake remains the same.
Why proxies don’t hide the TLS fingerprint
Using a proxy is commonly seen as a way to hide or change your online identity. To an extent that’s true. A proxy can mask the real IP of a single user on a specific device.
Don’t take the previous paragraph as moralizing - but note the temptation. Changing IP doesn't guarantee 100% anonymity; a service can find your real IP if it wants. There are methods and they are known. So using only a proxy without additional protections is an illusion of masking, nothing more.
This doesn’t work for multi-accounting. A proxy works at the network level and is limited to routing traffic through another IP. During an HTTPS connection, the TLS handshake happens directly between your device and the target server; the proxy only relays the already-encrypted data. Proxy only change some external attributes for a request:
- IP address the site sees;
- Geolocation (based on the proxy IP);
- Network route;
- Sometimes bypass regional restrictions.
- TLS fingerprint of your browser or script;
- Browser fingerprints: Canvas, WebGL, audio, fonts, etc;
- Client HTTP headers and characteristics (unless you change them manually);
- Other hardware/software indicators (screen resolution, timezone, plugins, etc).
How platforms use TLS fingerprinting for blocks
TLS fingerprinting is used by almost all major platforms fighting bots, fraud and multi-accounting. Many mid-sized services also plug in solutions to extract device fingerprints. If a web platform takes security seriously, it likely passively collects TLS fingerprints for every HTTPS request and compares them to known patterns. Now the players:
- Cloudflare and similar anti-bot services. Cloudflare analyzes TLS handshakes. If your JA3 hash doesn’t match any common browser template, the request is marked suspicious. Calls made by Python requests have a very different TLS signature than Chrome/Firefox and Cloudflare may block them or serve a captcha or JS challenge (Turnstile). Thus if a client reveals itself at the TLS stage, protection reacts regardless of IP.
- Social networks and ad accounts (Meta, TikTok, etc). Facebook and Instagram use strict fingerprint controls. Their systems link accounts with identical TLS fingerprints even if they’ve never logged in from the same IP. Blocking one profile can affect all linked accounts. Meta, besides TLS, uses dozens of other signals (Canvas, WebGL, sensors, etc) to build a multidimensional user profile. TikTok aggressively tracks multi-accounts - besides TLS it watches behavior (simultaneous logins, similar actions), but a shared TLS profile alone can be enough to link accounts.
- Marketplaces and e-commerce (Amazon, etc.). Large marketplaces use TLS fingerprinting not only against multi-account sellers but also to protect against mass scraping. Amazon fight automated price scraping by tracking identical TLS fingerprints across many requests. If you run a scraper through multiple proxies but use the same HTTP library (hence same fingerprint), the marketplace will detect it quickly. Within hours your proxy IPs may be flagged or banned because the system sees hundreds of requests with the same TLS signature and blocks the IP range as malicious.
- Advertising systems (Google Ads, etc). Google Ads checks TLS fingerprints when creating new ad accounts and during suspicious activity. If you try to create several accounts from different IPs but the same device, they’ll be flagged and sent to manual review (or preemptively blocked).
- Other platforms (LinkedIn, X, etc) also consider TLS fingerprints to varying degrees when detecting anomalies.
Important: TLS alone won’t necessarily out you if you use one device and multiple proxies. TLS is only one method used by anti-bot systems. Anti-fraud systems work by scoring (assigning penalty points), and TLS fingerprint is just one brick in the overall structure.
Ways to bypass TLS fingerprinting If TLS can out you, the logical approach is to change or mask it. Ideally, your client should look like an ordinary browser user or each automated stream should have different TLS profiles so they can’t be linked. How to achieve this? Methods used to counter TLS fingerprinting:
- Use a real browser via automation. The simplest way to generate a believable TLS packet is to open a real browser (Chrome, Firefox). Tools like Selenium, Puppeteer, Playwright together with Chromium/Firefox create authentic TLS handshakes. Even in headless mode modern browsers send the same ClientHello as in regular mode, so based on TLS alone they’re indistinguishable from real users. However, automating browsers can leave other traces - that’s a different topic.
- Use anti-detect browsers. Anti-detect browsers are one of the most reliable solutions. They are modified Chromium or Firefox builds that generate unique fingerprints per profile: Canvas, WebGL, TLS, etc. On startup they can assign a random but realistic TLS fingerprint drawn from a database of real devices or generate parameters on the fly, randomizing them into plausible combinations. Some allow manual tuning, but altering TLS is delicate - amateurs are not recommended to attempt it. The fingerprint must look authentic. If you create a combination that doesn’t exist in nature, smart systems will detect the forgery. Quality anti-detects avoid such mistakes and provide profiles indistinguishable from real users. Anti-detect browser + unique proxy per account is the standard multi-accounting solution. For web scraping anti-detect browsers are less convenient (harder to scale to hundreds of streams); they’re typically used selectively to pass tough captchas.
- Emulate the TLS packet programmatically. Professionals can manually set low-level TLS parameters. There are libraries and patches for HTTP clients that let you specify the order of ciphers, extensions, etc, thus emulating the TLS handshake of a desired browser.
- Rotate TLS fingerprints. If emulating a browser is hard, another approach is frequent changing of fingerprints so different streams look different. Some proxy providers or scraping services offer dynamic TLS profile replacement: your request passes through a special server that randomizes TLS parameters before connecting to the target site. It’s crucial that the substituted fingerprints also match real device fingerprints; otherwise you may create multiple suspicious profiles instead of solving the problem.
Each method has pros and cons in complexity and effectiveness. It’s best to combine approaches. For large-scale scraping use proxy rotation + TLS-spoofing utilities; for account management use anti-detect browsers + dedicated proxies per profile. Hiding your IP is not enough - you must also convince the server you’re a normal user.
Conclusion
The era when changing an IP address was enough for anonymity or to evade bans is long over. TLS fingerprinting has proven effective at detecting bots and linking accounts, so major internet platforms have widely adopted it. If you are being inexplicably blocked even when using clean residential proxies, it's very likely due to the TLS fingerprint of your client. Therefore, it’s important to monitor not only proxy cleanliness but also the digital traces your software leaves.
