ENTLS fingerprinting reads the shape of a TLS ClientHello. The server sees this message before the first HTTP request, so it can inspect the connection stack without waiting for page JavaScript.
JA3 and JA4 turn selected ClientHello fields into values that are easier to compare. Cipher suites, TLS extensions, supported groups, and protocol details can help distinguish a browser from a mobile app, malware sample, or basic HTTP library.
The useful part is consistency. A client may claim to be Chrome in its user agent. Its TLS handshake should still fit the browser and version behind that claim. If the two layers disagree, the request deserves closer inspection.
That mismatch is only one signal. A TLS fingerprint describes a client stack, not a person. Good risk systems compare it with IP history, HTTP behavior, and the wider browser fingerprint.
What Is TLS Fingerprinting?
TLS protects data sent between a client and a server. Before encryption is ready, both sides must agree on the connection settings. The client starts that negotiation with a ClientHello.
Different software builds this message in recognizable ways. Chrome uses BoringSSL. Firefox uses NSS. Many scripts reach OpenSSL through another library. Their supported options and extension patterns rarely line up by accident.
A CDN, web application firewall, or origin server can record selected fields and group connections with similar results. It does not need to decrypt the page or identify the user. The evidence already exists in the connection setup.
How Does TLS Fingerprinting Work?
A typical check follows five steps.
- The client opens an HTTPS connection.
- It sends a ClientHello with its supported connection options.
- The server or CDN reads selected fields from that message.
- A fingerprinting method normalizes and summarizes those fields.
- A security system compares the result with known patterns and other request signals.
Changing an HTTP user agent does not rebuild the underlying TLS stack. A request can therefore claim one browser family while connecting like another application.
That is a reason to inspect the request, not a reason to block it on sight. Corporate gateways, security software, unusual browser builds, and TLS intermediaries can all change what the server observes.
What Information Is Used in a TLS Fingerprint?
Fingerprint formats choose different fields and normalization rules. Most draw from the same parts of the ClientHello.
| Signal | What It Describes | Important Limit |
|---|---|---|
| TLS Version | Protocol Versions Offered by the Client | The Same Version Is Shared by Many Clients |
| Cipher Suites | Cryptographic Options the Client Supports | A List Describes Capabilities, Not a Person |
| TLS Extensions | Extra Features Included in the ClientHello | Modern Browsers May Change Extension Order |
| Supported Groups | Elliptic Curve and Key Exchange Groups | Results Can Change with Library Updates |
| Signature Algorithms | Signature Methods Accepted by the Client | Several Applications May Use the Same List |
| ALPN | Application Protocols Such as HTTP/2 | It Does Not Describe the Full HTTP Behavior |
| SNI Presence | Whether a Server Name Is Included | A Compact Fingerprint May Not Include the Name Itself |
| Field Order and Count | How the Client Structures the Message | Some Formats Sort Fields and Discard Order |
GREASE values also need special handling. Browsers add reserved values to test whether servers can tolerate future protocol changes. Both JA3 and JA4 ignore these values during normal fingerprint calculation.
These fields describe implementation choices. Two computers running the same browser build can produce the same normalized result.
What Is a JA3 Fingerprint?
JA3 is a method introduced by Salesforce researchers in 2017. It takes five ordered groups from the ClientHello.
- TLS or SSL version
- Accepted cipher suites
- TLS extensions
- Supported elliptic curves
- Elliptic curve point formats
JA3 joins the decimal values from those groups into one string. It then produces a 32 character MD5 hash. The hash is a compact lookup key. MD5 is not being used here to protect a password or prove data integrity.
The original JA3 project is now archived. JA3 still matters because years of network tools and threat intelligence depend on its values.
Its weakness is extension order. JA3 preserves it, while Chrome began changing that order across connections in 2023. One browser could then produce many JA3 hashes without changing its main capabilities. Fastly documented the effect across its network.
What Is a JA4 Fingerprint?
JA4 is a newer TLS client fingerprint format from FoxIO. It reduces the noise created by changing cipher and extension order.
A JA4 value has three sections.
| Section | Main Content |
|---|---|
a | Transport, TLS Version, SNI Presence, Cipher Count, Extension Count, and ALPN |
b | A Short Hash of Sorted Cipher Codes |
c | A Short Hash of Sorted Extension Codes and Signature Algorithms |
Sorting makes JA4 stable when the only difference is cipher or extension order. It also removes that order as evidence. A security team that needs the original sequence should keep the packet or raw handshake data.
JA4 belongs to the wider JA4 network fingerprinting project. JA4 covers the client hello. JA4S covers a server response. JA4H covers HTTP client behavior. They are separate fingerprints within the same family.
For a new collection pipeline, JA4 is often the cleaner starting point. JA3 still earns its place when historical matches and existing threat data matter. Many teams keep both during the transition.
JA3 vs JA4
| Area | JA3 | JA4 |
|---|---|---|
| Input | TLS ClientHello | TLS, QUIC, or DTLS Client Hello |
| Output | One MD5 Hash | Three Structured Sections |
| Cipher Order | Preserved | Sorted |
| Extension Order | Preserved | Sorted |
| GREASE Values | Ignored | Ignored |
| ALPN | Extension Presence Contributes | Short ALPN Representation Is Visible |
| Best Fit | Historical Matching and Existing Threat Data | Modern Grouping and Partial Comparison |
A match means that the selected handshake fields produced the same representation. Treat it as a client classification, not an identity match.
TLS Fingerprinting vs HTTP and Browser Fingerprinting
Real detection systems do not rely on one fingerprint. They compare signals from several layers, and each layer answers a different question.
TLS Signals
TLS signals describe how the client starts an encrypted connection. JA3 and JA4 belong here. The server can inspect them before page code runs.
HTTP Signals
HTTP signals include header names, header order, protocol choice, and request structure. HTTP/2 adds SETTINGS frames, window sizes, and pseudo header order. These details can support a TLS finding, but they come from a different stage of the request.
Browser Signals
Browser signals come from headers and browser APIs. Fonts, screen details, Canvas output, a WebGL fingerprint, and audio fingerprinting can reveal whether the page environment fits the network stack. Most of these checks need page code to run.
Behavior Signals
Behavior signals describe what the client does over time. Request rate, navigation order, session history, mouse input, and repeated actions are central to bot detection. A correct handshake cannot make suspicious behavior legitimate.
The useful decision comes from agreement across layers. A Chrome user agent, Chrome style TLS handshake, expected HTTP/2 settings, and working browser APIs tell a consistent story. Human intent still has to be judged from the session and its behavior.
What Can a TLS Fingerprint Reveal?
A TLS fingerprint is useful for estimating:
- Whether a client resembles a browser, app, bot, or general HTTP library
- Which TLS implementation or application family may have created the connection
- Whether the handshake fits the reported user agent
- Whether a connection pattern has appeared before
- Whether traffic belongs to a known group in a threat database
It is a poor basis for claiming:
- The name or identity of the user
- Ownership of an account
- A unique physical device
- The exact operating system in every case
- Whether the request is harmful
- Whether two matching requests share one operator
Cloudflare uses JA3 and JA4 inside Bot Management as part of a larger signal set. Its JA3 and JA4 documentation also notes that a fingerprint may be missing on an unencrypted request or when session resumption avoids a new handshake. Missing data should not be treated as suspicious by default.
Where Is TLS Fingerprinting Used?
TLS fingerprints earn their value in repeatable security work.
- Threat hunting can group encrypted connections from known malware families.
- Bot management can compare browser claims with the connection stack.
- Fraud systems can add the result to an account or transaction risk model.
- API teams can separate expected clients from unusual libraries.
- Web application firewalls can monitor or rate limit known fingerprint groups.
- Operations teams can find old or unexpected TLS implementations.
The privacy concern is just as practical. TLS data does not depend on cookies or local storage. When it is combined with a broader browser fingerprint, it can support recognition across visits.
Does a VPN or Proxy Change a TLS Fingerprint?
A VPN normally changes the route and public IP. It does not rebuild the browser ClientHello. The destination still sees the handshake created by the browser.
A standard HTTP CONNECT or SOCKS tunnel usually behaves the same way. It carries the connection without terminating TLS, so the client still negotiates directly with the target.
The result changes when an intermediary terminates TLS and creates a new upstream connection. In that case, the destination sees the ClientHello produced by the intermediary. Corporate inspection gateways and some managed network services can work this way.
This is why a proxy, VPN, and antidetect browser affect different parts of the environment. The destination sees the fingerprint of whichever software establishes the TLS session it receives.
Incognito mode also has a limited effect. It changes local storage and browsing history. It does not normally replace the browser TLS implementation.
How to Read a TLS Fingerprint Test
A test page reports what its own server observed. It is a comparison tool, not a pass certificate.
Use a controlled comparison.
- Run the same test twice in the same browser profile.
- Record the browser version, protocol, JA3, and JA4 values.
- Restart the profile and repeat the test.
- Test again after a browser or operating system update.
- Note whether a VPN, proxy, or inspection gateway changed the connection path.
The result only becomes useful when the test conditions are known.
| Result | Likely Meaning | What It Does Not Prove |
|---|---|---|
| Same JA4 Across Profiles | The Normalized TLS Fields Matched | The Profiles Are the Same Device |
| New JA3 on Each Connection | Extension Order May Be Changing | The Client Changed Completely |
| JA3 or JA4 Is Missing | No Suitable New TLS Handshake Was Available | The Site Cannot Assess the Request |
| User Agent and TLS Family Differ | The Connection Needs More Context | The Request Is Malicious |
Different test sites may calculate or display values in different ways. Start with repeated results from one service before comparing hashes from elsewhere.
TLS Fingerprinting and Browser Profiles
A browser profile keeps the browser environment, cookies, proxy settings, and related configuration together. MoreLogin users can choose a browser kernel and manage signals exposed through browser APIs in the profile settings. These include Canvas, WebGL, AudioContext, WebRTC, language, timezone, and media devices.
TLS sits below those browser API settings. Changing Canvas output does not change JA3. Editing the user agent text does not rebuild the ClientHello.
MoreLogin does not publicly list a separate JA3 or JA4 control in its current profile settings. Claiming that every profile receives a unique TLS hash would therefore go beyond the available product information. Browser version, runtime, protocol, proxy design, and connection path all affect what a server observes.
For authorized team work, a multi account browser keeps cookies, proxy assignments, and browser environments separate. This reduces accidental overlap between profiles. It cannot control how every third party security system classifies traffic.
The same limit applies to browser automation. A workflow running in a real browser uses a different network stack from a basic script library. It still needs permission, sensible request rates, and reliable error handling.
TLS Fingerprinting FAQ
Is a TLS fingerprint unique to one device?
No. It usually describes a client application or TLS implementation group. Many devices running the same browser build can share one result. An update can also change the fingerprint on the same device.
Can a website see my TLS fingerprint?
Yes. The server or CDN that receives the connection can inspect the ClientHello. A test page can display the value returned by that server.
Does changing the user agent change JA3 or JA4?
Not by itself. The user agent is an HTTP value, while JA3 and JA4 come from the TLS handshake. Editing one header does not rebuild the network stack.
Why can two browsers have the same JA4?
JA4 sorts selected lists and groups similar handshakes. Browsers with the same engine and TLS capabilities can share a result. That does not mean the browsers are linked.
Does clearing cookies change a TLS fingerprint?
No. Cookies are stored session data, while TLS fingerprints come from connection setup. A site may use both, but clearing one does not reset the other.
Does Encrypted Client Hello stop TLS fingerprinting?
Encrypted Client Hello protects sensitive parts of the handshake, including the requested server name. The network can still see an outer ClientHello, and the destination still handles the full connection. ECH improves privacy without removing every TLS signal.
Key Takeaway
TLS fingerprinting shows how a client starts an encrypted connection. JA3 remains valuable for historical matching. JA4 is usually easier to work with when modern browsers change list order.
The fingerprint becomes meaningful when it agrees with HTTP, browser, network, session, and behavior signals. One hash can guide a risk decision. It should not make that decision alone.
