TLS fingerprinting: What it is and how it works

Being able to identify the web clients visiting your site can make all the difference when it comes to spotting fraud. In this article, we’ll dig into TLS fingerprinting, how it works under the hood, and how it can help you get a clearer picture of your traffic while keeping bad actors out.

What is TLS?

Transport Layer Security (TLS) is a web protocol that helps you stay secure online. To be more precise, it encrypts web-based communications between a client (like your browser) and a web server using cryptographic algorithms. Before TLS can be used for secure communication, the client and server go through a process known as the TLS handshake.

This handshake is a series of messages back and forth between the client and server that help  establish which encryption to use, verify each other’s identity, and ensure the integrity of the data being shared. Once the client and server are synced, they can prevent eavesdropping or man-in-the-middle attacks.

You can easily see when a connection is using TLS by looking for HTTPS in the URL. HTTPS is an implementation of TLS with the HTTP protocol. Many browsers also show some kind of secure lock icon as an indicator of TLS. You may also hear TLS being called SSL; this is because TLS evolved from SSL (or Secure Sockets Layer), and often they get used interchangeably.

What is TLS fingerprinting?

TLS fingerprinting is the identification of a client based on what it sends in its messages during a TLS handshake. The way different clients send data and even the order in which they send it is unique. You can combine these details to generate a fingerprint that allows you to infer information about the client, like the operating system or browser version. ISPs can also use some of this information to guess which websites you’re visiting, though they can’t see the specific content of your activity on HTTPS sites.

Identifying a client can be helpful for fraud detection and prevention because malicious users often try to conceal their identities to perform multiple fraudulent activities on a website. Along with identifying users using cookies and browser fingerprinting, TLS fingerprinting can be another identification layer for your anti-fraud stack.

How does a TLS Handshake work?

The handshake begins when the client asks the server to start a secure session. Each version of TLS is a little different, but let’s examine how the current version, 1.3, works at a high level. Because of the different TLS versions available and options for encryption methods (also known as cipher suites), the client needs to let the server know what it supports.

First, the client sends a ClientHello message that includes its supported TLS version, a list of cipher suites, and a client random value. The message also lists supported groups, which are elliptic curves that the client can use for ECDHE secure key exchange. These are like an agreement protocol that lets two parties establish a shared secret over an insecure connection. The ClientHello also carries a key-share extension, where the client includes its ephemeral public key for one of those curves. This lets the server immediately compute a shared secret with the client’s key, enabling fast and secure key agreement.

Next, the server reviews that request and chooses compatible options. It responds with a ServerHello that confirms the TLS version, selected cipher suite, chosen key-share, and includes its own server random value. From that point, both sides derive shared keys, and the rest of the handshake is encrypted.

There are a few more steps in the handshake process that are not relevant to TLS fingerprinting. The server then sends a series of messages that include information on any additional settings, its certificate, and proof that it controls the private key. It ends with a Finished message that confirms the integrity of everything sent so far.

Once that series of server messages is done, both sides exchange final confirmation messages that are encrypted with the session key. Along the way, the client validates the server’s certificate by checking its signature, confirming the hostname matches, and ensuring it hasn’t expired. Once they’ve confirmed integrity and authentication, the handshake is complete, and all further communication uses fully encrypted application data.

Recognizing a user client with TLS Fingerprinting

The initial parameters sent between the client and server in a TLS handshake are exposed in plaintext, making them key fingerprinting vectors. For example, part of the ClientHello is a list of ciphers supported by the client. This list is dependent on the TLS library used by the client, like the following:

Client	TLS library
Firefox	NSS
Microsoft	SChannel
Apple Safari	Apple Secure Transport Layer
Google Chrome	BoringSSL

While TLS 1.3 caps the possibilities for supported ciphers at five, each implementation can trim down or reorder that list, adding variation that contributes to fingerprinting uniqueness.

For example, in the following image, you can see details on the cipher and TLS versions for Google Chrome and Firefox:

A client might alter its User-Agent string to display another browser version and operating system, but its ClientHello can sometimes reveal its actual browser version and operating system. Additionally, different versions of the same browser can contain a different list of preferred ciphers.

Additional details like extensions (e.g., SNI, ALPN) and supported groups (elliptic curves) are also combined to form a TLS fingerprint that can reliably identify the client’s browser and operating system. These fingerprints are distinctive enough to flag bots or other malicious activity, like someone trying to spoof their browser to hide from fraud prevention tactics, but they’re typically not unique to individual users, meaning different clients can share the same fingerprint. 

Real-world applications of TLS fingerprinting

TLS fingerprinting is used every day to detect threats, enforce security policies, and analyze client behavior. Below, we’ll take a look at some examples of how TLS fingerprints help identify bots, block attacks, and flag outdated or vulnerable clients.

JA3

JA3 was developed by a team at Salesforce and open-sourced in 2017. It gathers the following fields in the ClientHello during the TLS Handshake:

• TLS version
• Accepted ciphers
• List of extensions
• Elliptic curve
• Elliptic curve formats

Once it has these fields, it combines them in order, using a comma to delimit fields and a hyphen to delimit each value in the field.

The resulting string is hashed using the MD5 algorithm, which is easily consumable and shareable. This string is the JA3 TLS client fingerprint, which you can then compare with known application fingerprints to indicate whether a client is malicious.

JA3S

JA3S expands on JA3 and includes the server-side of TLS communication. Two clients have the same JA3 fingerprint, which can prove less helpful in differentiating a legitimate client and a malicious one. With JA3S, the fingerprint is generated using additional fields from the ServerHello message, including:

• TLS version
• Ciphers
• TLS extensions

The server responds in a specific way based on the content and order of the information sent by the client. These variations in the way the server responds to different clients make the overall fingerprint more distinct. Combining JA3 and JA3S helps reduce the chance that a legitimate and malicious client produces the same hash, lowering false positives and improving detection and blocklisting accuracy.

JA4 and JA4+

JA4 is a more recent fingerprinting format designed to be more flexible and resilient than JA3. Starting in 2023, many browsers began to randomize the order of data sent in TLS handshakes, making it unreliable for JA3 fingerprinting. JA4 and the JA4+ suite capture similar handshake metadata like cipher suites, extensions, and elliptic curve groups, but add context such as the ALPN value, SNI, and transport protocol (TCP vs. QUIC). JA4 also improves consistency across TLS 1.3 and QUIC (used in HTTP/3), where extension order and structure often vary.

Together, this suite of fingerprinting tools provides a more robust system for detecting bots, evasion techniques, and suspicious traffic patterns, especially in modern encrypted environments. As TLS evolves, new cryptographic schemes like post-quantum hybrid handshakes (e.g., Kyber) are being tested and deployed. These add new extensions and key-share formats to the handshake, which fingerprinting tools like JA4 are designed to accommodate.

Bot detection

A bot is an automated application programmed to perform specific actions on other devices, often resulting in a cyberattack or abuse of a service. In some cases, a network of these devices is used to complete larger-scale cyberattacks, commonly known as a botnet. Researchers can track botnets to identify what they have in common, such as some form of malware, and then share the research results with the security community in the form of IOCs (Indicators of Compromise).

These IOCs will contain specific details, like the TLS library that the malware has employed to secure its communication. According to WatchGuard, in Q4 of 2023, 55% of malware used TLS to conceal communications.

When you use TLS fingerprinting on your network, you can compare the results with the IOCs to determine if the connected client is infected with malware and thus a bot. Of course, that’s not the end of it. Bot users know about TLS fingerprinting and are taking steps to circumvent it.

Once you detect a bot, you can block its IP address or employ a bot protection service. If you have a website that asks users for input, you should implement some form of bot detection. Consider trying our BotD open-source library or our commercially available Bot Detection Smart Signal if you have significant or sophisticated bot traffic.

DDoS protection

Distributed Denial of Service (DDoS) is an attack that aims to overwhelm a target website or infrastructure with junk traffic using a botnet. One notable example is the Mirai botnet, which was blamed for taking Twitter offline for a few hours earlier this year.

Once you detect a surge of traffic to your website or network, analyzing the ClientHello messages can help group devices that share the same TLS fingerprint. Many botnets use identical or similar TLS configurations, making them detectable through patterns in cipher suites and extensions. While this approach isn’t foolproof — especially against more sophisticated and evasive bots — it can aid in flagging and blocking malicious traffic.

Vulnerable Applications

Applications are regularly updated to patch bugs and improve security. If TLS fingerprinting detects a ClientHello that matches an outdated browser version still using deprecated versions of TLS (which have been deprecated for weak cryptography), you can prompt the user to update their browser. As a last resort, you may choose to block access to your site or service until they upgrade, helping reduce exposure to known vulnerabilities and ensuring secure communication.

Get smarter data for your anti-fraud stack

TLS fingerprinting offers a powerful way to spot unusual or unwanted traffic without invasive tracking. At Fingerprint, we mix TLS fingerprinting along with over 100 signals to provide reliable visitor identifiers with industry-leading accuracy. Combined with our suite of Smart Signals, such as Bot Detection, Browser Tampering Detection, Virtual Machine Detection, and more, you can detect bots, identify suspicious devices, and reduce fraud. Want to see our visitor insights in real-time? Start a free trial or have a chat with our team to learn how we can help you protect your site and your users.