How a TLS handshake gives your software away
The first thing your browser sends to an encrypted website is a list of everything it knows how to do. The list crosses the wire in plain text, before any encryption has switched on, and the order of its contents was fixed by the people who wrote the software. Anyone positioned to read it can compress it into a short label, and that label names the program making the connection more reliably than the program’s own self-description ever will.
The greeting that travels in the clear
An encrypted session cannot begin encrypted. Both ends first have to settle which protocol version they will speak, which cipher will protect the traffic, and how they will exchange keys, so every connection opens with a negotiation called a handshake, and the client speaks first. Its opening message is the client hello, and it reads like a filled-in form: the protocol versions the software will accept, the cipher suites it supports arranged from most preferred to least, the optional extensions it can switch on, and, tucked inside some of those extensions, further lists covering the curves it will use for key exchange and the signature methods it trusts.
Because this message exists to arrange the encryption, the encryption cannot cover it. The server reads it plainly, and so can anything sitting between you and the server. Everything after the handshake is sealed. The introduction that sets up the seal is spoken out loud.
Same protocol, different accents
You might expect every modern browser to send roughly the same greeting. They differ, and they differ consistently. Each implementation was written by a different team making its own decisions about which ciphers to offer and in what order, which extensions to include, and how to arrange the whole thing. Two versions of the same browser can disagree with each other, because the lists shift as features get added and old ciphers get retired.
The underlying library matters as much as the browser sitting on top of it. A program that borrows its encryption from the operating system inherits the operating system’s habits. A program that ships its own library carries that library’s signature instead. None of the ordering is arbitrary. It reflects choices, priorities, and years of accumulated history specific to one software stack, which is exactly why it repeats so faithfully from connection to connection.
Boiling the greeting down to a label
Take the whole introduction, the version, the ordered ciphers, the ordered extensions, the curves, the signature methods, and write it out as one long string in an agreed format. Run that string through a hash and you get a short, stable label. The same software in the same configuration produces the same label every time it opens a connection. Change the software and the label changes with it.
Notice what the label actually describes. It says nothing about who you are and nothing about the content you are about to request. It describes the machinery placing the call: this program, on this system, built against this encryption library. A handful of characters that a server can look up, compare, and remember.
A judgement formed at the doorway
The handshake is the first thing on the wire. It arrives before the request for the page, before any cookie is handed over, before a single image or script has loaded, before the site’s own code has had any chance to run inside your browser. A server can therefore compute this fingerprint within the first few milliseconds of contact and decide how to treat a visitor while the visitor still believes nothing has happened yet.
Most identification techniques need the page to load before they can start work. This one runs ahead of the content entirely, which is a large part of why defensive systems value it so much.
The costume check
Every ordinary web request also carries a user agent, a plain text line in which the client describes itself: this browser, this version, this operating system. That line is trivially easy to edit, and automated clients edit it constantly. The handshake underneath is far harder to dress up, because it comes from deep inside the encryption library rather than from a label anyone can rewrite in a config file.
So a server holds the two up against each other and asks whether the greeting matches the claim. A visitor announcing itself as a mainstream browser should greet the way that browser greets. When the user agent says polished consumer browser and the handshake says bare scripting library, the mismatch is loud and it arrives before anything else has happened.
I run mobile proxy lines for a living, and this mismatch sits underneath a good share of the detection complaints that reach me. The customer assumes the address gave them away. Often the address was fine. The client was wearing a browser costume over a body that greeted like an automation framework, and the server noticed during the introduction, before the first page was ever served.
Nothing to clear
The property that unsettles people is that this fingerprint is stored nowhere on your device. There is no file to find and no cookie to delete, because nothing gets saved between connections. The greeting is generated fresh, out of the running software itself, every time a connection opens. Clearing your history does not touch it. A private window sends exactly the same hello, because a private window runs the same browser built on the same library. Short of switching to genuinely different software, or modifying the software’s behaviour at a deep level, the greeting stays constant, day after day, connection after connection.
Who actually reads it
People describe the technique as a tracking tool, and trackers do use it, since anything that recognises returning software helps someone recognise returning devices. Most of its daily use sits on the defensive side, though. Fraud teams use it to spot a flood of login attempts that parade thousands of different user agents while sharing the single fingerprint of one automation tool. Bot detection services use it as a first filter at the network edge, a cheap way to separate obvious machines from probable humans before spending real effort on deeper checks. Content delivery networks lean on it to triage traffic when a flood arrives.
It earns that front-line position because it comes in early and costs almost nothing to compute, which is precisely what you want from a first filter.
The imitation game
Once the people running automation understood the tell, they set about closing it. Tools now exist whose whole purpose is to reproduce a real browser’s greeting, matching the cipher order, the extension list, the curves, all of it, so the fingerprint lines up with the identity the user agent claims. Up to a point, that works.
The defenders refine in response. They inspect subtler corners of the greeting that are genuinely difficult to reproduce from outside a real browser, and they watch whether the rest of the connection then behaves the way the claimed browser would. Imitation also carries a built-in trap. The copyist freezes a known good greeting and reuses it, while the browser it copied keeps updating. Within a few release cycles the frozen greeting matches a version that no longer exists anywhere in the wild, which is itself a fresh tell. Each side studies the other’s latest move, and neither is ever finished.
The people it misreads
The same signal that flags a fraud operation also flags people who have done nothing wrong. A privacy focused browser with a greeting the server has never catalogued reads as suspicious purely for being rare. A company that routes its staff through a security appliance can have every employee’s connection rewritten into one odd, uniform handshake matching no ordinary browser, and watch the whole workforce get flagged in bulk. An older device, a niche operating system, an accessibility setup, an honest but unusual configuration, any of these produces a greeting outside the expected set and quietly pays for the difference.
The technique cannot separate malice from unfamiliarity. It knows one thing about you: whether your hello resembles the crowd’s. Careful operators treat a strange greeting as one weak signal among many, a reason to look closer rather than a reason to slam the door, because a system that blocks every unfamiliar handshake spends its life turning away real people. Some browser makers have responded from the other direction, smoothing their handshakes toward a common shape so that more of their users blend into one large, unremarkable crowd, which remains the safest place to stand.
The introduction you never hear
We picture our exposure online as living in the things we can see and manage: the cookies, the history, the accounts we sign into. Some of the most identifying material leaves the machine before any of that comes into play, in the opening packet of a connection, written by the developers of your software and repeated faithfully every time it says hello. By the time a page appears on screen, the introduction has long since been made, and for many of the systems watching, the introduction alone is enough to recognise the same machinery the next time it comes knocking.
More on the machinery running underneath the ordinary internet at The Hidden Internet.
Get new guides and videos first — join the Telegram channel.