Forem: Rom

How We Reverse Engineered a TLS Fingerprinting System

Rom — Thu, 16 Apr 2026 11:33:19 +0000

Modern anti-bot infrastructure doesn't just look at what you send - it looks at how you connect. TLS fingerprinting is one of the most effective and least-understood layers of bot detection. Here's how we pulled it apart.

The problem

At Clerix, we build real-time intelligence infrastructure. That means our systems need to maintain clean, stable connections to extract structured data at scale - deterministically, reliably, and without triggering detection layers that have nothing to do with the content of the request.

One day, connections that had been stable for months started failing silently. No HTTP error. No rate limit. Just... nothing. The connection would complete, a valid response would come back, and then subsequent requests from the same session would be met with garbage data or empty bodies.

We ruled out IP reputation. We ruled out cookie or session state. We eventually isolated it to the TLS handshake itself.

What is TLS fingerprinting?

When a client initiates a TLS connection, it sends a ClientHello message. This message contains:

Cipher suites - the list of encryption algorithms the client supports, in order
Extensions - features like SNI, ALPN, session tickets, supported groups
Compression methods
TLS version

The combination of these fields - especially the order - forms a near-unique fingerprint of the client library being used.

The two dominant fingerprinting standards you'll encounter are:

JA3 - MD5 hash of: TLS version, ciphers, extensions, elliptic curves, and elliptic curve point formats. Developed by Salesforce, widely used.

JA3N / JA3S - Variants that normalize extension order or fingerprint the server response.

Here's what a JA3 string looks like before hashing:

771,4866-4867-4865-49196-49200-159-52393-52392-52394-49195-49199-158-49188-49192-107-49187-49191-103-49162-49172-57-49161-49171-51-157-156-61-60-53-47-255,0-11-10-13172-16-22-23-49-13-43-45-51-21,29-23-24-25,0

Breaking it down:

771 = TLS 1.2
4866-4867-... = cipher suite list (decimal)
0-11-10-... = extension types
29-23-24-25 = supported elliptic curves
0 = EC point formats

Every major HTTP client has a recognizable JA3. curl has one. Python's requests library has one. Node's https module has one. They're catalogued and blacklisted.

Capturing the handshake

Our first step was passive observation - capturing what our outbound ClientHello actually looked like from the server's perspective.

We stood up a simple TLS inspection proxy using mitmproxy with a custom addon:

from mitmproxy import ctx
import struct

class TLSInspector:
    def tls_client_hello(self, data):
        hello = data.client_hello
        ctx.log.info(f"SNI: {hello.extensions.get('server_name')}")
        ctx.log.info(f"Ciphers: {hello.cipher_suites}")
        ctx.log.info(f"Extensions: {[e.type for e in hello.extensions]}")

addons = [TLSInspector()]

We also used Wireshark with the tls display filter and exported the ClientHello bytes directly:

tls.handshake.type == 1

Then we fed the raw bytes into a local JA3 calculator to confirm what hash we were generating. The result matched what we expected: our hash was showing up in commercial threat intel feeds as "non-browser."

What makes a fingerprint detectable

The key insight is that TLS fingerprints aren't just about which features you claim to support - they're about the default behavior of the underlying library.

Python's ssl module, for example, hardcodes cipher suite order based on OpenSSL's compiled defaults. Even if you upgrade TLS versions, the order is deterministic and well-known.

Specific tells we found:

Cipher suite ordering - Python/OpenSSL prefers different suites than Chrome's BoringSSL
Extension presence and order - Chrome includes a compress_certificate extension (type 27). Most HTTP libraries don't.
GREASE values - Chrome injects random "garbage" values (GREASE - Generate Random Extensions And Sustain Extensibility) into the handshake to prevent ossification. JA3N was specifically designed to normalize these out.
Padding extension - Chrome pads its ClientHello to avoid certain sizes that trigger middle-box bugs. Pure library clients don't.

Spoofing the fingerprint

Once we understood the signal, we had several options:

Option 1: Use a browser engine directly

Tools like Playwright/Puppeteer use actual browser TLS stacks. Effective, but heavyweight for infrastructure that needs throughput.

Option 2: Patch OpenSSL at runtime

Possible, fragile, not portable.

Option 3: Use a library that gives you control

This is the approach that scaled. Libraries like curl-impersonate compile curl against BoringSSL (Chrome's TLS library) and expose Chrome's exact cipher/extension order. There are Python wrappers (curl_cffi) that expose this at the session level:

from curl_cffi import requests as cffi_requests

session = cffi_requests.Session(impersonate="chrome120")
response = session.get("https://target.example.com")

Under the hood, this sends a ClientHello that is byte-for-byte identical to Chrome 120. Same cipher suites, same extensions, same GREASE, same padding.

We benchmarked this against our previous stack:

Approach	JA3 Hash	Detection rate	Throughput
`requests` + `httpx`	`d9f4be3f...` (Python/OpenSSL)	High	High
Playwright	Chrome-identical	Very low	Low
`curl_cffi` (Chrome120)	Chrome-identical	Very low	High

curl_cffi won on both axes.

JA4 - the newer generation

JA3 has known weaknesses: it's easy to spoof once you know it's being checked. JA4 was introduced by FoxIO in 2023 as a more robust successor.

JA4 encodes:

Protocol version
SNI presence
Number of ciphers
Number of extensions
First ALPN value
Sorted cipher suites (order-independent)
Sorted extensions (order-independent)

The sorting is the key difference - it makes JA4 resistant to order-shuffling spoofs. However, it also means the feature set itself becomes the signal. If you claim to support exactly the extensions that Chrome supports, you'll match Chrome's JA4 - regardless of order.

This is an arms race. Detection moves to behavioral signals when the cryptographic ones get spoofed.

What we learned

A few things that weren't obvious at the start:

TLS fingerprinting is almost always one layer in a stack. Defeating JA3 alone rarely wins. Real detection systems combine JA3/JA4 with HTTP/2 fingerprinting (stream weights, header order, SETTINGS frames), TCP fingerprinting (TTL, window size, options), and behavioral analysis. Solving the TLS layer just moves you to the next one.

Normalization matters more than individual values. The most suspicious thing isn't any single cipher - it's inconsistency. A ClientHello that claims to be Chrome but uses Python's HTTP/2 stack is incoherent and trivially flagged.

Impersonation fidelity has to go all the way down. curl_cffi handles the TLS layer. But you still need to match HTTP/2 pseudo-header order, SETTINGS frame parameters, and window update behavior. Fortunately, since curl_cffi uses curl's full stack (including nghttp2), the HTTP/2 framing matches Chrome's as well.

The bigger picture

TLS fingerprinting is a microcosm of a broader dynamic in the infrastructure space: the signal keeps moving lower in the stack. It started with IP reputation, moved to cookies and headers, then to TLS, now increasingly to TCP and even timing characteristics.

At Clerix, this is the layer we operate at. Understanding these mechanisms - not just working around them but properly modeling them - is what makes the difference between infrastructure that works in controlled conditions and infrastructure that holds up under production adversarial conditions.

If you're building anything in this space and want to go deeper, the two most useful starting points are:

tlsfingerprint.io - passive fingerprinting service
tls.peet.ws - shows your live JA3/JA4/HTTP2 fingerprint
The curl_cffi source on GitHub - the implementation is surprisingly readable

Clerix is real-time intelligence infrastructure for agentic systems. We extract structured data from the web at enterprise scale.

clerix.io

Your Agentic Workflows Are Making Decisions on Stale Data and You Probably Don't Know It

Rom — Sun, 12 Apr 2026 11:39:02 +0000

Here's a scenario most engineering teams don't catch until it costs them.

You build an outbound agent. It pulls prospect data, scores leads, routes them, maybe even drafts a first message. The pipeline runs clean. Metrics look fine. Then someone on the sales team flags that half the contacts are wrong — titles changed, companies pivoted, people left months ago.

You trace the issue back. The data source was cached. The cache was three weeks old. The agent had no way to know.

This is the silent failure mode of agentic systems built on static or semi-static data layers.

Why This Matters More When Agents Are in the Loop

When a human is making a decision, stale data is annoying but manageable. The human notices inconsistencies, cross-references, asks questions. They have a sense that something feels off.

Agents don't have that instinct. They're deterministic. They act on what they're given. If the input data is three weeks old, the agent produces a confident, well-structured output based on a three-week-old reality. No flags, no uncertainty signals, just action.

This is a qualitatively different problem from the one we had with dashboards and reports. The cost of stale data compounds when autonomous systems are consuming it at scale.

The Specific Signals That Go Stale Fastest

Not all data ages equally. Static fields — names, addresses, founding dates — hold up reasonably well. But the signals that actually drive high-value agentic decisions are often the ones with the shortest shelf life.

Think about what an intelligent workflow actually needs to act on:

Current role and seniority at a given org
Whether a company is actively hiring in a specific function
Recent funding events or ownership changes
Whether a product or service is still being offered
Current pricing tiers or contract structures

These signals can shift in days. Scraping or caching them on a weekly or monthly cadence, and then routing them into an autonomous decision loop, introduces a class of error that's hard to observe and harder to fix after the fact.

What Real-Time Actually Means (and What It Doesn't)

The word real-time gets used loosely. It's worth being precise.

Polling every 24 hours is not real-time. A webhook that fires when a batch job finishes is not real-time. A cached API response with a TTL of six hours is definitely not real-time.

Real-time, for the purposes of agentic signal consumption, means: when the agent queries for a data point, it gets the current state of that data point at that moment — not the last time someone thought to check.

That requires infrastructure that can extract from primary sources on demand, return typed structured output the agent can consume without interpretation, and do this reliably at whatever query volume your system produces.

Most teams trying to solve this end up in one of two failure modes. They either build their own scrapers and extraction pipelines, which become a maintenance burden that grows faster than the rest of the product, or they accept the caching tradeoff and quietly absorb the quality degradation.

How Teams Are Actually Solving This

The pattern that's started to work is treating real-time signal extraction as infrastructure rather than a feature. You don't build your own power grid — you connect to one.

Clerix operates as exactly that kind of infrastructure layer. It handles real-time extraction from primary data sources, returns deterministic typed JSON, and is designed to operate inside agentic loops where reliability and output consistency matter.

The practical result is that your agent's decision quality becomes a function of your reasoning logic rather than of your data freshness. Which is where it should be.

The Engineering Question Worth Asking

If you're building or operating agentic workflows right now, one diagnostic question worth running: what is the actual data freshness of the signals feeding your agents at the point of decision?

Not the freshness of your source integrations in theory. The actual age of the data, at query time, for a typical run.

If you can't answer that precisely, the answer is probably worse than you'd like it to be.