TLS Fingerprinting Through Proxies: JA3, JA4, Tunnels

Before an HTTPS request is sent, the client and server negotiate TLS. The client's ClientHello advertises protocol capabilities such as supported cipher suites, extensions, groups, signature algorithms, and application protocols. Libraries and browsers build that message differently, so selected fields can be summarized into a fingerprint.

A fingerprint helps group similar handshakes. It is not proof of a person, device, browser authenticity, intent, or safety. Many clients can share one fingerprint, and one client can produce different values after an update or configuration change. Servers commonly combine TLS information with HTTP, IP, cookie, account, rate, and behavior signals.

With an HTTP CONNECT tunnel or a pass-through SOCKS route, the client normally establishes TLS end to end with the destination through the tunnel. In that design, the destination observes the client's ClientHello; the proxy changes the network path and source address but does not terminate the TLS session.

A TLS-intercepting corporate gateway, debugging proxy, malware scanner, translating relay, or other terminating intermediary behaves differently. It accepts one TLS connection from the client and creates another toward the destination. The destination then fingerprints the intermediary's outbound TLS stack. A reverse proxy or CDN also terminates the visitor connection and may use a different upstream handshake to the origin.

Do not infer behavior from the word “proxy” alone. Inspect the certificate chain, product documentation, tunnel method, packet capture, and destination-side observation for the actual route.

JA3 builds a string from the TLS version, ordered cipher suites, ordered extensions, elliptic curves or supported groups, and point formats, then hashes that string with MD5. The hash is a compact label; the unhashed field string is more useful when explaining why two clients differ.

Standard JA3 implementations explicitly ignore GREASE values. GREASE reserves placeholder values so implementations continue to tolerate new protocol options, as specified in RFC 8701. Removing those reserved values prevents their randomized selection from creating a different JA3 on each connection. If a reflector reports changing JA3 values solely because it retained GREASE, it is not applying the standard normalization described by the JA3 project.

JA3 can still vary because a client changes cipher or extension order, supported groups, TLS configuration, library version, or handshake path. MD5 is used as a compact fingerprint label here, not as a security proof.

JA4 reorganizes TLS client characteristics into a readable prefix and hashed components. Among its design choices, it sorts selected ClientHello extensions, reducing variation among modern browser handshakes and making partial comparisons possible. The broader JA4+ family defines separate methods for server responses, HTTP clients, certificates, SSH, TCP, and other protocols.

JA4 is not a unique identity and should not be treated as one. A value can be missing, shared, or changed by protocol, version, configuration, session resumption, or intermediary behavior. Record the raw handshake context and implementation version when using it for diagnostics. Also review the licensing terms for JA4+ components; JA4 itself and other family members do not all use identical licensing.

When the same client opens pass-through tunnels through residential, mobile, or datacenter exits, the destination can observe different source networks while receiving the same client-generated TLS fields. In that specific architecture, changing the exit is an IP-origin change, not a TLS-client change.

The result must be measured rather than assumed. A gateway update, TLS termination, HTTP/3 conversion, upstream proxy, custom transport, or destination-side normalization can change what is observed. Likewise, a stable JA3 or JA4 does not mean the entire connection is identical: TCP behavior, HTTP/2 settings, headers, cookies, timing, and account context may still differ.

Cloudflare documents JA3 and JA4 as TLS-client identifiers available to Enterprise Bot Management customers. Its documentation notes that fingerprints can be missing, including for non-encrypted traffic, some Worker paths, skipped Bot Management processing, and session resumption. Cloudflare also combines fingerprints with additional signals rather than treating one hash as a verdict.

Cloudflare's Bot Score ranges from 1 to 99: lower values are more likely automated, while 30 through 99 are grouped as likely human. Granular scores require Enterprise Bot Management. They are available through Cloudflare rules, Workers, analytics, and logs for configured customers; they are not a universal public response header that any requester can read.

A known or unusual fingerprint can contribute to a decision, but public documentation does not support a universal claim that one JA3 or JA4 always produces a particular score or block.

Test a destination and network path you own or have permission to assess. Hold the client binary and configuration constant, then compare direct and proxied paths one variable at a time. Record the proxy protocol, whether TLS is pass-through or terminated, destination certificate, DNS path, exit network, TLS version, ALPN, raw ClientHello, JA3 field string, JA3 hash, JA4 value, UTC timestamp, and failures.

Use a packet capture at a point where collection is authorized and a destination-side reflector you control. Preserve raw artifacts, commands, dependency lockfiles, operating-system and binary versions, proxy settings, and a SHA-256 manifest. Repeat each path so random or session-specific behavior is not mistaken for a structural difference.

Do not publish credentials, private traffic, session tokens, or full third-party user addresses. If the gateway is managed by another organization, obtain permission before capturing or probing it.

For defenders, TLS fingerprints can help group traffic, investigate a sudden client change, or add context to rate, account, and behavior controls. Build rules from observed good and bad traffic on the system you operate, monitor false positives, and allow fingerprints to age as software updates.

For client developers, consistency matters: the claimed application, TLS behavior, HTTP protocol, headers, and runtime should reflect the software actually being used. If an authorized integration is rejected, use the destination's API, allowlist, service account, test environment, or support process rather than attempting to conceal the client.

Network origin and TLS behavior answer different questions. Choose a proxy because an authorized workload needs that route or location, not because a product promises that changing an IP will make an unrelated client indistinguishable from a browser.