TLS fingerprinting
Encryption begins with an introduction.
Before encrypted HTTP content can move, a client sends a ClientHello describing the protocols and cryptographic features it supports. The exact contents and order can identify the software making the connection before the page loads and add a transport layer to the browser's wider fingerprint.
- Observed at
- TLS termination
- Primary message
- ClientHello
- Stored ID
- Not required
- Describes
- Client implementation
Before the page exists
The connection is classified before JavaScript runs.
TLS protects the content exchanged after negotiation. But the endpoint terminating TLS must first receive enough of the handshake to choose compatible parameters. That early negotiation is where the client exposes a recognizable shape.
- 01Network connection
TCP connects, or QUIC begins for HTTP/3.
transport evidence - 02ClientHello
The client advertises versions, ciphers, extensions, groups, and ALPN.
fingerprint observed - 03ServerHello
The server selects compatible parameters and continues key establishment.
negotiation - 04Encrypted HTTP
Only now does the request and most page data travel inside the protected session.
application data
The destination—or CDN, load balancer, security service, or proxy terminating TLS—can inspect the handshake it receives. An on-path observer may see outer handshake metadata, but Encrypted ClientHello can conceal the inner ClientHello and server name from that observer. Page JavaScript cannot directly read the raw ClientHello it used.
ClientHello anatomy
The fingerprint comes from choices, presence, and order.
A fingerprinting system discards values that should change every connection, selects fields that describe implementation behavior, and serializes the remaining structure. The same ingredients in a different order can produce a different result.
length: variable03 03compatibility field32 byteschanges per connection0–32 bytesnot a stable client trait13 01 · 13 02 · 13 03 · c0 2b · …list + orderserver_name · groups · signatures · ALPN · key_share · …presence + order + valuesTLS 1.3 · TLS 1.2Protocol versions
The versions the client is prepared to negotiate.
4865 · 4866 · 4867 · …Cipher suites
Supported cryptographic combinations, sent in a client-chosen order.
SNI · groups · ALPN · key shareExtensions
Optional protocol features. Presence and ordering can be highly characteristic.
X25519 · P-256 · P-384Supported groups
Key-exchange groups supported by the TLS implementation.
RSA-PSS · ECDSA · …Signature algorithms
Signature schemes the client can validate or produce.
h2 · http/1.1ALPN
Application protocols the client wants to use after TLS completes.
Fingerprint simulator
Change the ClientHello. Change the fingerprint.
Compare simplified client profiles. This simulator never opens a connection; it shows how a collector can normalize ordered handshake fields into a compact identifier.
- Transport
- TCP
- TLS version
- 1.3
- Cipher order
- 4865 · 4866 · 4867 · 49195
- Extension order
- 0 · 10 · 11 · 13 · 16 · 43 · 45 · 51
- Groups
- 29 · 23 · 24
- ALPN
- h2 · http/1.1
1.3|4865-4866-4867-49195|0-10-11-13-16-43-45-51|29-23-24|h2Illustrative digeste6586f13A mainstream browser release tends to emit a stable family pattern shared by many users of that build and platform.
Educational digest only—not a live JA3 or JA4 result. A webpage cannot inspect the raw ClientHello that carried its own request.
From handshake to identifier
JA3 made the recipe portable. Newer formats add structure and normalization.
There is no single universal TLS fingerprint. Different systems select, normalize, serialize, and hash handshake features in different ways.
771,4865-4866-4867…,0-10-11-13…,29-23-24,0compact JA3 hashJA3 removes GREASE values, serializes selected ClientHello fields, and hashes the resulting string. Because list order is preserved, reordering can alter the hash.
JA4 separates human-readable characteristics from hashed components and normalizes ordering differently. Its wider family also fingerprints other protocols and server behavior.
Who creates the handshake?
A VPN changes the route. A TLS proxy changes the speaker.
The important question is which component opens the encrypted connection that the destination receives.
The packet is routed through another network, but the browser-generated ClientHello reaches the destination substantially intact.
The proxy terminates the first session, then creates a second session with its own TLS implementation and fingerprint.
Private mode isolates local browsing state; it normally uses the same TLS library and browser build.
The VPN changes the network path and source IP, while the browser still creates the ClientHello.
Cipher preferences, extensions, GREASE behavior, and protocol support can change between releases.
Chrome, Firefox, Safari, curl, Python, and automation stacks can use different TLS implementations or configurations.
The proxy receives one handshake and creates a new one toward the destination.
HTTP/3 carries TLS 1.3 inside QUIC; modern fingerprint schemes account for the transport.
Read the result carefully
A TLS fingerprint identifies software behavior, not a person.
Millions of browsers can share a fingerprint. Updates and configuration changes can replace it. Its value grows when an observer combines it with IP history, HTTP headers, cookies, account state, timing, or browser-side signals.
Meaningful defenses
The strongest defense is a common, coherent handshake.
Random-looking does not automatically mean anonymous. A rare or internally inconsistent TLS profile can become more distinctive.
- 01Share a browser profile
Use a TLS configuration shared by a large population rather than inventing a unique mixture of suites and extensions.
- 02Match the layers above it
The TLS handshake, ALPN, HTTP version, header order, User-Agent, and browser behavior should describe one plausible client.
- 03Control the component that connects
A routed tunnel does not rewrite the browser’s handshake. Changing the downstream fingerprint requires controlling or terminating the TLS connection.
- 04Treat ECH precisely
Encrypted ClientHello can hide the inner ClientHello and server name from on-path observers. It does not hide the handshake from the service that terminates it.