DEV Community: ParallaxGrain

Let's Encrypt for Internal Domains: What CT Logs Make Public

ParallaxGrain — Sun, 15 Nov 2026 17:06:11 +0000

Let's Encrypt for internal domains works: the DNS-01 challenge proves you control a domain without any server answering from the internet, and wildcard certificates come the same way. What it does not do is keep the name private. Every certificate a browser trusts is written to public Certificate Transparency (CT) logs. A service on a private address behind a VPN therefore still has a public hostname, and its issue dates and renewals are on record for anyone to read.

A public certificate means a public name. Choose a certificate per host, a wildcard or a private CA by how much of the name you can afford to publish, and protect every service as if its name is already known.

What a certificate publishes the moment it is issued

Before issuing, a CA submits a precertificate to the logs. It is the certificate-to-be plus a critical extension, called the poison, that makes standard clients refuse it. The logs answer with signed timestamps (SCTs), and the CA embeds them in the real certificate. Nearly every CA works this way, so the hostname is public before the certificate exists. Chrome and Apple platforms both require signed proof from logs run by at least two separate organizations, so a publicly trusted CA cannot skip the step and a site owner cannot opt out.

The log entry holds the whole certificate. For a domain-validated certificate, the kind Let's Encrypt issues, that means the names it covers, the issuer and the validity dates. Neither the server's address nor what it runs is in the entry. The leak is the name, which usually tells you what the host is for. Internet-wide scans already aggregated certificates, but the logs make the collection complete and early, and let anyone search it by name without connecting to your server. The entries for a domain, read as a list, give a stranger:

the services you run, from labels such as vault, grafana, jenkins or vpn;
products and customer names before any announcement;
the date each host appeared and whether its certificate keeps renewing;
a ready target list, if the same names also resolve in public DNS.

Newer logs publish their contents as plain files that any client can download, and some add a compact list of just the names. For logs that Chrome accepts, the time a log may take to include an entry is capped at one minute for these static logs and four hours for the older kind. Soon after a Let's Encrypt certificate is logged, automated crawlers can find the new hostname and request it, and a public web server sees that traffic in its access log. Logs are append-only, so a name stays listed after its certificate expires or is revoked. The full Certificate Transparency background covers logs, SCTs and browser enforcement in more detail.

Let's Encrypt for internal domains: what DNS-01 solves and what it publishes

Let's Encrypt checks control of a name with a challenge. HTTP-01 needs a web server answering on port 80. DNS-01 needs only a TXT record in the domain's public DNS, so it works for hosts that are not exposed to the internet, and only DNS-01 can issue a wildcard. The renewing machine then holds a DNS API credential, and one that can edit your whole zone is a risk on a web server, so scope it narrowly or run the validation elsewhere.

The name must sit under a domain you own in public DNS: public CAs may not issue for names that do not end in a registered top-level domain, so names ending in lan or local are out.

On the publishing side, Let's Encrypt submits every certificate it issues to CT logs. Its default lifetime is 90 days, with renewal advised every 60, and six-day certificates are opt-in. Industry rules cap lifetimes at 200 days now, 100 from March 2027 and 47 from March 2029, so a per-host certificate puts the same name into the logs more often each year.

Wildcard certificate subdomains: what stays hidden

A wildcard certificate for *.lab.example.com covers exactly one label below lab.example.com. It matches vault.lab.example.com and rejects a.vault.lab.example.com or api.example.com. The log shows the wildcard and the zone label, lab, and none of the hosts under it, so the individual service names never appear.

What a wildcard does not hide:

Guessable names. A dictionary of common labels such as mail, dev, vpn and staging, each checked in DNS, finds hosts whatever certificate they use.
Any host that also gets its own certificate, even once, from another CA or a test run.
Names published in public DNS. Internal-only DNS answers, often called split-horizon, close that route.

Are wildcard certificates less secure?

A wildcard is less secure in one respect: what a stolen key is worth. Its private key sits on every machine that serves a name under it, so the weakest host exposes all of them. Whoever holds the key can impersonate any name in the zone to anyone whose traffic they can redirect. Give each environment its own zone and its own wildcard, and keep the key off machines that do not serve it. The domain owner can also narrow who may issue at all: CAA records list the authorized CAs and can carry a separate rule for wildcard names.

Private certificate authority for internal names

A certificate from your own CA never reaches the public logs. The logs do not accept certificates from CAs that browsers do not trust by default, and CT applies only to publicly trusted CAs, so a certificate signed under a root you installed yourself is outside it. For names only your organization uses, a private CA is the usual answer. The price is operational. You run the CA or rent a hosted one, guard its key, and install its root on every device that must trust it. That rules out visitors' phones and anything you do not manage.

Approach	What public logs show	Who trusts it	What it costs
Public CA, one certificate per host	Every hostname, at issuance and at each renewal	Every browser and device	Names, dates and renewal rhythm are public
Public CA, wildcard	The wildcard and the zone label	Every browser and device	One key on every host, one label deep, DNS credentials for issuance
Private CA	Nothing, the logs refuse its certificates	Only devices that installed your root	You run the CA and distribute the root

Certificate transparency monitoring: what to do about it

Logs also work in your favor, because a certificate you did not request shows up in them as well. A monitor reads the logs for your domain and sends an alert for each new certificate. Cloudflare's CT Monitoring, generally available on every plan since August 2026, is opt-in and emails you about certificates for your domain from any other issuer. It only watches your own names, so a certificate for a lookalike domain raises no alert.

Look up your domain as an outsider would. The Subdomain Finder from packet.guru combines Certificate Transparency data from crt.sh with roughly a thousand common names, checks each in DNS and lists the names that exist now, showing the address, country and network of each. A name that only survives in an old certificate and no longer resolves is dropped, so search crt.sh as well for the full history.
Sort every name as reachable from outside or internal. An internal name with its own public certificate is a candidate for a wildcard on a separate zone, or for a private CA. The two combine: a public wildcard for services outside visitors must reach, a private CA for the rest.
Treat every label as public. Keep customer names, unreleased products and role hints such as prod or admin out of hostnames that will ever get a public certificate.
Put real access control on the service itself. Login, a VPN or an allowlist has to carry the protection, because the name will not.
Check what each server presents: the certificate it serves lists its Subject Alternative Names, issuer and validity window, and any SSL checker shows them. Then turn on monitoring and publish CAA records.

Tor vs VPN vs Proxy: Who Can See Your Traffic

ParallaxGrain — Fri, 13 Nov 2026 14:00:00 +0000

Tor vs VPN vs proxy usually gets argued on speed and price. A better first question is which watcher you want out of the picture and which one you are willing to let in. The café Wi-Fi, your ISP and the site you open each see part of your connection by default, and each of the three tools removes some of them by adding another.

A VPN or a proxy hands one operator both your address and where you go. Tor is built so that no single relay holds both.

What a VPN provider can see

A VPN puts all of your device's traffic into one encrypted connection to the provider's server, which then opens the real connections for you. The Wi-Fi and the ISP now see one destination, the VPN server, plus how much you send and when. The provider sits where your ISP sat. It sees your real IP address, the address of every site you reach, the content of any plain HTTP page and, on HTTPS sites, the site name your browser announces at the start of the connection (the SNI field) unless the site uses Encrypted Client Hello, which encrypts it. Names looked up through the provider's DNS resolver, the server that turns site names into addresses, are readable too.

The tunnel doesn't hide that it exists. WireGuard, for one, doesn't disguise itself and leaves obfuscation to layers above it, so a filter can pick VPN traffic out without reading it.

What the provider stores is the open question, and a no-logs promise can't be checked from outside, because nobody can inspect what a server didn't write down. An independent audit narrows the doubt but describes one configuration at one moment. A VPN fits when the watcher you worry about is the network around you and you trust the company more than that network.

What a proxy operator can see

A proxy relays requests only for the apps configured to use it. The operator sees your IP address and the destination of everything those apps send, which is the VPN provider's position with less cover on the way there. How much cover depends on the type:

HTTP proxy, plain HTTP site. The app hands over the whole URL, so the operator reads the request and the response.
HTTP proxy, HTTPS site. The app sends a CONNECT request that names only a host and a port. After that the proxy forwards bytes in both directions without reading them, but it already knows the host.
SOCKS5. In everyday use nothing is encrypted: the destination, an IP address or a hostname, crosses the network readable, and so does the password if the proxy requires a login.
HTTPS proxy. The connection to the proxy is wrapped in TLS, the encryption behind HTTPS, so the Wi-Fi sees only the proxy. The operator's view doesn't change.

Two details decide who else learns where you browse. A proxy may pass your address on to the site in a Forwarded header, the standard way for a proxy to tell a site who the original client was. And a SOCKS5 client that looks up the site name itself sends that lookup to your own resolver, outside the proxy. Handing the name to the proxy moves the lookup, and the knowledge, to the operator. A proxy therefore fits a narrow job: giving one app another address.

What each Tor relay sees

Tor sends traffic through a circuit of three volunteer-run relays. Your client wraps the request in one layer of encryption per relay, and each relay can remove only the layer addressed to it.

Guard, the entry. It sees your IP address and that you are connecting to Tor. It can't see the site.
Middle. It sees the relay before it and the relay after it, and neither you nor the site.
Exit. It sees the site you reach, resolves the name, and reads the content when the connection isn't HTTPS. It doesn't see who you are, and the site sees the exit's address instead of yours. Exits have been caught tampering with unencrypted connections.

Your ISP sees a connection to a Tor relay. Relay addresses are public, so a network can recognize or block them, and a website can challenge or block exit traffic, which many do. A bridge, a relay missing from the public list, makes the first hop harder to block.

The guard stays the same for months, on purpose. With a fresh entry and exit for every circuit, an attacker who watches a slice of the network would get a new chance to land on both ends each time. A fixed guard turns repeated chances into a single draw.

Tor vs VPN: which one is more secure

A VPN wins on speed and coverage: it carries a whole device's traffic rather than TCP streams alone, to a server you chose. Tor wins on how little any single party learns, and pays for it in speed, because traffic bounces through volunteers' servers around the world. Each also fails somewhere specific. A VPN fails at its operator: a compromised or careless company exposes your address next to your destinations in one spot. Tor fails when one party can watch both ends. An observer who sees you and also sees the site or the exit can line up the timing and volume of what goes in with what comes out, and Tor doesn't defend against that.

All three fail at the login form. Log in to an account through a VPN, a proxy or Tor and the site knows who you are, whatever address it sees. Tor keeps your location apart from your destination, and what you type is still up to you.

Stacking a VPN on Tor is an advanced setup rather than a free upgrade. Configured wrongly, it can weaken the protections Tor gives you, and the usual advice is to skip it unless you know how to configure both. The reason people reach for it, hiding Tor use from the network they are on, is what a bridge is for.

Which design fits which threat

Threat	Fits	Who still sees what	Where it fails
Your ISP or the Wi-Fi owner	VPN, or Tor	VPN: the company sees your address and destinations. Tor: the guard knows your address, the exit knows the site	Both show that you use them, unless Tor goes through a bridge
The site seeing your IP	VPN, Tor or a proxy	The site sees a VPN, exit or proxy address	An account you log in to; the reputation of a shared address
Both at once	Tor Browser, or a VPN if one company may see everything	Tor: no relay holds both ends	Timing match when both ends are watched
A network that blocks Tor or VPNs	Tor with a bridge	The bridge sees your address, the network sees a connection to it	Some countries detect certain bridges
A single app that needs a different address	Proxy	The operator sees that app's traffic	Plain HTTP and SOCKS5 proxies leave the first leg readable

Shadowsocks, SSH tunnels, iCloud Private Relay, multi-hop VPNs and the two orders of Tor plus VPN are compared in the full VPN vs proxy vs Tor guide.

See whose address a site gets

Start with your normal connection and run the Privacy & Trust Index scan. The DNS Privacy card shows who answers your lookups. ISP DNS means your provider answers them and can read them.
Turn on the VPN, set the proxy in your browser, or open Tor Browser, and scan again. The IP Reputation card names the kind of address the site now sees, with labels such as VPN / PROXY and TOR EXIT NODE when the address is on a known list. A shared address inherits the history of whoever used it before, which the IP reputation guide covers.
Read DNS Privacy again. NO DNS LEAK means the VPN or proxy handles your lookups, DNS LEAK means they still escape to a regular provider, and DNS VIA TOR means the exit node resolves the names. Each result tells you who reads the site names you look up.

Are Passkeys Phishing Resistant? What Each Login Method Stops

ParallaxGrain — Tue, 10 Nov 2026 07:20:06 +0000

Passkeys are phishing resistant: a fake login page cannot collect anything that works on the real site. That is one attack out of several, and every login method stops some and walks into others. A password falls to a fake page, an SMS code to a SIM swap, an authenticator code to a page that passes it on in time, and malware already on the device can get around all of them.

A password or a code is something a fooled person can hand over. A passkey holds a key that signs only for the site it was made for, so a fooled person has nothing to hand over.

What each login method stops

The password column assumes one memorable or reused password. The manager column assumes a unique random password for every site.

Attack	Password	Password + SMS code	Password + app code	Password manager	Passkey
Fake login page	Fails	Fails, the page relays the code	Fails the same way	Partly, autofill skips lookalike addresses	Stops
Reused password (credential stuffing)	Fails	Stops the login, the password stays exposed	Same as SMS	Stops, one password per site	Stops, nothing to reuse
Leak of the site's database	Weak passwords fall first	Cracked password still needs the code	Same, unless the code seed leaks too	Contained to one site	Stops, only public keys are stored
SIM swap	Not involved	Fails	Stops	Not involved	Not involved
Malware on your device	Fails	Partly	Partly	Partly	Partly
Lost or replaced phone	Not involved	Number moves to the new SIM through the carrier	Codes are gone unless backed up	Vault syncs, the master password unlocks it	Synced: restored on sign-in. Device-bound: gone

A manager fills a login only on the address saved with it, so a lookalike domain gets nothing automatically, but a password pasted in by hand defeats that. On an infected device no method is safe: a keylogger (software that records keystrokes) reads a typed password, and a stolen session cookie, the token a site gives your browser after sign-in, works whatever login produced it.

Password hashing, salt and credential stuffing

A site should never store your password, only a hash of it: a one-way scramble that can be recomputed but not reversed. A salt, a random value stored beside each hash, makes two accounts with the same password produce different hashes, which defeats precomputed lookup tables. Good schemes are also deliberately slow. A leaked table still lets an attacker guess offline at their own pace, and the passwords people choose most often fall first.

Composition rules do not change that. P@ssw0rd has a capital, a digit and a symbol, and it appears in leaked-password data more than six million times. Current standards no longer ask sites to demand mixed character types. They ask them to reject passwords already known from leaks and to accept long ones, with 15 characters as the floor when a password is the only factor.

The same example in a Short:

Credential stuffing is how leaks get used. Attackers take email and password pairs from one breach and try them, automatically, on other sites. It works only where a password was reused.

Why SMS codes and authenticator apps still get phished

An SMS code travels over the phone network, and a SIM swap puts it in the wrong hands: the attacker persuades your carrier to move your number to a SIM they hold, and every text, codes included, goes to them. That makes SMS the weakest of the common second steps. Microsoft starts retiring SMS and voice codes in Entra ID, its work and school sign-in, in February 2027.

An authenticator app avoids the carrier. It computes a short code on the phone from a secret shared with the site and the current time, in 30-second steps by default, so a SIM swap never touches the code. The weakness is that the code knows nothing about where you type it. A fake page asks for the password, then for the code, and forwards both to the real site before the code expires. Any code a person reads and types can be relayed like this, whether it arrived by text or came from an app.

Are passkeys phishing resistant? What the browser checks

Creating a passkey makes your device generate a key pair for that one site. The private key never goes to the site: it stays in the device's protected storage or in a credential manager. The site keeps the public key, which can verify a signature but cannot make one. At sign-in the site sends a fresh random challenge, so a recorded answer is useless the second time, which is how a replay attack is defeated. You unlock the key with a fingerprint, face or PIN, and the device signs two things: the challenge and the web address of the page making the request. The browser fills in that address itself, not the page and not you.

A page on another domain cannot even request the real site's passkey: the browser compares the domain being asked for with the page's own address and refuses a mismatch, and the real site would turn down a response that was signed for another address.

The fingerprint or face stays on the device. The site receives a signed response and a flag saying the user was verified.

The catch: recovery, fallbacks and the device itself

Adding a passkey does not remove the password or the SMS code from an account unless you do. A phishing page can claim that passkeys are unavailable and offer those instead, and the weaker method is then phished as before. A Microsoft account can drop its password altogether.
Synced passkeys come back when you sign in to the Apple or Google account, or to a manager such as 1Password or Bitwarden, from a new device and pass its checks, so that account becomes the thing to protect. Apple's keychain recovery needs the Apple Account password, an SMS reply and a device passcode. A device-bound passkey, on a security key for example, is gone with the device, which is why a second one should be registered.
A passkey protects the sign-in, not the computer. Attacks published in August 2026 let malware already running on a Windows PC take over accounts protected by Google-synced passkeys in Chrome and extract all of them.
The lock screen is part of the trust: anyone who can unlock the device can use its passkeys, so create them only on devices that are yours. On a computer that is not yours, scan the QR code it displays and approve on your phone; the passkey stays there.
Portability is still uneven. A synced passkey lives in one provider's vault, and moving it between managers needs a shared format. The Credential Exchange Format is a proposed standard and iOS 26 can export to apps that support it, but the transfer protocol is still a working draft.

Sync, device-bound keys and each platform's recovery are covered in the full passkey guide.

What to do today

Add a passkey first to the accounts that can reset all the others: your main email address and the Microsoft, Apple or Google account you use most. Game accounts follow, since PlayStation, Nintendo and Roblox let you sign in with one.
Create each passkey on a device you own, then add a second one on another device or a hardware security key and test it before changing anything else.
Remove the fallbacks the site lets you remove, the password and the SMS code, and keep the recovery codes offline.
For sites without passkeys, give each account its own long random password from a manager or from the password generator on packet.guru, which makes strong random passwords locally in your browser. Use an authenticator app for the second step instead of SMS.
Look up your email addresses in Have I Been Pwned and replace the password of any site you still use that shows up in a breach.

TCP Fingerprinting: What One Packet Tells a Server About Your OS

ParallaxGrain — Sat, 07 Nov 2026 12:32:05 +0000

A web server learns something about your machine before it parses a single header. The SYN packet that opens every TCP connection carries a hop budget, a window size, a segment size and a list of options, and your operating system picked all of them. TCP fingerprinting reads those values and guesses the OS behind the connection. It needs no JavaScript and no cookies, and the visitor never sees it happen.

A browser can claim any operating system. The first packet shows what the kernel behind the connection does, and a mismatch check only needs the two to disagree.

How TCP fingerprinting reads a SYN packet

The handshake starts with the client's SYN, short for synchronize. The standards define each field but leave most values to the implementer, so every network stack fills the SYN in with its own defaults. Four of them carry signal, strongest first:

The TCP options and their order. The standard fixes how an option is encoded but not where it sits in the list, so each kernel has its own layout. In default settings, Linux writes SACK permitted and the timestamp right after the MSS and puts window scale last, Windows puts window scale second and sends no timestamp, and Apple systems send a timestamp and finish with an end-of-list byte. On their own these usually separate the three families, though versions and settings shift them.
Initial TTL, the hop budget in the IP header. It is coarse, as the next section shows.
Window size, how much data the sender accepts before it expects an acknowledgment, and the window scale option that multiplies it. Both follow buffer memory, version and tuning, so one system can show several numbers and different systems can show the same one.
MSS, the biggest payload the sender will take in one segment. It describes the link, not the OS: the MTU minus the IP and TCP headers, so systems on the same Ethernet link normally send 1460 over IPv4.

TTL 64 vs 128: the clue everyone quotes

TTL, time to live, starts at the OS default, and every router on the path subtracts one. The server receives the starting value minus the number of hops, then rounds up to the nearest common start: 64, 128 or 255. A reading of 54 means a start of 64 and ten routers on the way. A reading of 117 means a start of 128 and eleven.

The rule of thumb says 64 is Linux and 128 is Windows. Android runs on the Linux kernel and starts at 64, and so do macOS and iOS. That makes TTL a one-question test: Windows or Unix-like. It cannot tell a Linux server from a Mac, and either side can change it with a single system setting. IPv6 calls the field the hop limit, and a router can announce which default hosts should use, so the network may override what the OS would pick.

Passive OS fingerprinting vs Nmap OS detection

Nmap's OS detection is the active kind. It sends up to 16 TCP, UDP and ICMP probes to open and closed ports on the target, built to exploit gaps in the standard, and matches the replies against a database of thousands of fingerprints. Passive tools such as p0f send nothing. They read packets that cross the wire anyway, often just one SYN. A website has little choice but the second kind for its visitors. Nmap itself works best when it finds at least one open and one closed TCP port, and a probe aimed at a visitor's public address lands on the home router, not on the laptop behind it.

	Passive (p0f, JA4T)	Active (Nmap OS detection)
Packets the observer sends	None	Up to 16 probes
What it studies	The client's SYN; p0f also reads the server's SYN+ACK	Replies to crafted probes
What it needs from the target	A connection that arrives anyway	A reachable address and, for best results, a mix of open and closed ports
Does the target notice	No	Probes can set off alarms
Typical user	A website classifying its own visitors	An admin auditing a network they own
Typical answer	OS family and rough generation	A ranked OS and version guess

The active tools are visible to the passive ones: p0f ships signatures for Nmap's SYN scan and for its OS detection probes. JA4T takes the passive route and writes four values into one string a server can log per connection: window size, option order, MSS and window scale. It leaves out the TTL, which shifts with distance. The signature formats and licensing are covered in the passive OS fingerprinting guide. Application code rarely sees a SYN, so the reading usually happens at the edge: a firewall, load balancer or sensor.

TCP fingerprint anomaly: when the packet and the browser disagree

The server fingerprints whoever opened the connection to it. A tunnel VPN carries your packets as they are, so your SYN arrives intact. A proxy opens a second connection, so the website is looking at the proxy's kernel, often Linux on a rented server. A CDN or load balancer that ends TCP shows the origin its own SYN and keeps yours for itself, and Tor does the same at its exit relays. VPN vs proxy vs Tor lays out which tools forward packets and which open a connection of their own.

Set that against the browser's claim, which an extension can rewrite in seconds, and you have a TCP fingerprint anomaly. Take a Windows laptop behind a Linux proxy: the User-Agent says Windows, the SYN says Linux, and the address often sits in a hosting network. Each signal is weak alone. Anti-fraud systems tend to weigh such signals together, so the visitor can end up with a CAPTCHA or a second sign-in prompt instead of a block. Automation hits the same check: a scraper in a Linux container can send any User-Agent, but its kernel sends a Linux SYN.

The two directions carry different weight:

A Linux SYN under a Windows or Apple claim is common and often innocent: a proxy, a relay service or a corporate gateway.
A Windows or Apple SYN under a different claim is rarer, because few proxy servers run on those systems. It usually points to an edited claim, from a browser extension or an anti-detect profile.

p0f has a flag for this check: it reports 1 when the User-Agent differs from the OS in a way proxying can explain, and 2 for an outright mismatch.

A mismatch does not say which layer is wrong, or why. Matching proves little in the other direction, because some proxy providers offer a setting that makes the proxy's SYN look like another system. The SYN gives a family, not a version or a device, and p0f's own label for recent Macs adds "sometimes iPhone or iPad". It also needs TCP to be there at all. HTTP/3 runs on QUIC over UDP and has no SYN, though browsers first hear about HTTP/3 through a response header or a DNS record, so many connections still start on TCP.

Check your own TCP fingerprint

Go to the Privacy & Trust Index and wait for the scan to complete. The TCP/OS Fingerprint card compares the system your connection points to with the one your browser reports.
Read the status. OS MATCH means the two agree. OS MISMATCH means the connection reveals a different system than the browser reports, and the details can name what carried it, such as a VPN or a datacenter network. OS HIDDEN BY TOR means an exit relay opened the connection. PROBE UNREACHABLE means the fingerprint could not be read this time.
Open the Connection Fingerprint panel lower on the page. Its TCP / IP rows show the Detected OS and Initial TTL, the raw Window, MSS and Window Scale values, the Options and your JA4T. Compare the TTL with 64 and 128, and the options with the layouts above.
Turn a VPN or proxy on and scan again, then compare the Detected OS and the status with the first run.

JA4 Fingerprint: What It Reads and Why JA3 Stopped Working

ParallaxGrain — Thu, 05 Nov 2026 14:00:00 +0000

Two separate connections from the same Chrome open with a ClientHello, the opening message of each HTTPS handshake, and the extensions inside it come in a different order each time. Hash that list in the order it arrives, as JA3 does, and one browser produces a new fingerprint on nearly every connection. A JA4 fingerprint sorts the list first, so both connections give the same string, one that a rule or a database can match. Cloudflare, AWS WAF and Auth0 all read JA4 now.

A TLS fingerprint names the software that opened a connection. It says nothing about who is using that software or why.

Why the JA3 fingerprint stopped working

JA3 came out of Salesforce in 2017. It takes five fields from the ClientHello (TLS version, cipher suites, extensions, elliptic curves and curve point formats), lists the values in ClientHello order and hashes the string with MD5. The same application sends the same hello and gets the same 32-character hash, so defenders could trade hashes of known malware between organizations. The JA3 repository is archived now, and its author maintains JA4 instead.

JA3 broke on ordering, which TLS leaves free: extensions may appear in any sequence, except that pre_shared_key must come last. Servers that key on Chrome's exact layout would make it hard for Chrome to change TLS later, so since Chrome 110 (2023) it shuffles its extensions on every new connection. The shuffle happens inside BoringSSL, Chromium's TLS library, which draws a fresh permutation for each handshake, so browsers built on Chromium's network stack inherit it. A JA3 rule written for one Chrome handshake now matches only the connections that happen to repeat that order.

GREASE, the reserved placeholder values Chrome mixes into its lists to keep servers tolerant of unknown options, did not cause the breakage: JA3 skips them. Randomizing the cipher list, called cipher stunting, is another known way to dodge JA3.

What a JA4 fingerprint reads

JA4, published by FoxIO in 2023, reads the same ClientHello and prints three parts joined by underscores. Taken apart, a Chrome fingerprint like t13d1516h2_8daaf6152771_02713d6af862 says:

The first part is plain text. It opens with t for TLS over TCP (q is QUIC, d is DTLS), then 13 for the highest TLS version the client offers, here 1.3, then d if a server name was sent (i if not). Next come the counts of cipher suites (15) and extensions (16), and h2, the first and last character of the client's first ALPN protocol. That is the one it prefers: HTTP/2.
The second part is the cipher suites sorted in hex order, hashed with SHA-256 and cut to 12 characters.
The third part is the extensions sorted the same way (server name and ALPN left out, because part one covers them), followed by the signature algorithms in the order sent, hashed and cut the same way.

GREASE values are ignored everywhere. Sorting is what cancels the shuffle: every ordering of the same extensions sorts to the same list. The signature algorithms stay in sent order, so a client that shuffled those would still change part three. For cipher suites the order is a real preference ranking, so sorting trades a little detail for stability.

The readable first part is useful without any database lookup. Browsers advertise h2 there, while many scripting clients offer no ALPN at all and show 00 instead.

JA4 is one member of the JA4+ family: JA4S fingerprints the server's reply, JA4H the HTTP request, JA4T the TCP handshake, JA4L latency, JA4X certificates. The licenses differ. The TLS fingerprint itself is open source under BSD 3-Clause, as JA3 is, while the other family members use the FoxIO License, which allows internal and academic use and not selling it inside a product without a separate license.

JA3 vs JA4 side by side

	JA3	JA4
Introduced	2017, Salesforce	2023, FoxIO
Fields read	TLS version, ciphers, extensions, elliptic curves, point formats	Transport, TLS version, server name present or not, ALPN, ciphers, extensions, signature algorithms
Order	As sent	Ciphers and extensions sorted, signature algorithms as sent
GREASE	Skipped	Skipped
Transport	Not recorded	First character: t, q or d
Output	One 32-character MD5 hash	Three readable parts
Same Chrome, two TCP connections	Two different hashes	The same fingerprint

The full background on both formats and on the JA4+ family is in the TLS fingerprinting guide.

How bot detection uses a TLS fingerprint

The handshake comes before the first HTTP request, and its shape comes from the TLS code inside the client, not from anything a script writes into a header. A script's HTTP library brings its own TLS defaults, while Chrome uses BoringSSL. A server therefore holds a claim (the User-Agent says Chrome) and a measurement (the handshake says otherwise), and three checks turn that into a signal:

Claim against handshake. A Chrome User-Agent on a handshake that looks like a script library is a mismatch. A JA4 nobody has seen before proves nothing by itself, because it can be just a new browser release.
One layer against the next. HTTP/2 has its own fingerprint: which SETTINGS values the client sends and in what order, the WINDOW_UPDATE increment, any PRIORITY frames and the sequence of the request pseudo-headers. TCP has JA4T. Different parts of the client produce each layer, so a script that copies Chrome's ClientHello but keeps its library's HTTP/2 defaults disagrees with itself.
The fingerprint's own record. Cloudflare's Bot Management can report, for each JA4, what happened over the last hour of its traffic: the share of requests with browser user agents, how many distinct IPs use it, how much it requests. A fingerprint seen almost only on non-browser traffic reads differently from one that a great many browsers share.

Matching all of this is possible. Libraries such as curl_cffi impersonate a real browser's ClientHello and HTTP/2 settings. Another route is to drive an actual browser, whose handshake is genuine by construction. Then the TLS layer has nothing to flag and the decision falls to other signals, which fake browser detection covers for headless and anti-detect browsers.

What a TLS fingerprint can't prove

A proxy that terminates TLS replaces the fingerprint. Antivirus that inspects HTTPS and corporate gateways decrypt the traffic and start a second connection of their own, so the server sees the gateway's handshake, which can disagree with an honest browser's User-Agent.
Encrypted Client Hello (ECH) hides the real hello from the path. It wraps the true ClientHello inside an outer one. A network observer can fingerprint only the outer hello, while the server that decrypts it still reads the inner one.
Over HTTP/3 a browser has a second JA4, one starting with q instead of t, because TLS runs inside QUIC. The first QUIC packet is protected with keys derived from a connection ID sent in the clear, so any observer along the route can read the ClientHello in it.

See your own TLS fingerprint

Start the Privacy & Trust Index scan and wait until every card has a result.
Find the TLS / JA4 Fingerprint card. It reads your TLS and HTTP/2 handshake and compares both with the browser your User-Agent reports. The answer is CONSISTENT, ENGINE MISMATCH, SPOOFED, AUTOMATION TOOL or UNVERIFIED. ENGINE MISMATCH can also come from a corporate proxy or a brand-new browser build, and UNVERIFIED means your fingerprint is not in the reference set yet, so nothing is concluded.
Scroll to the Connection Fingerprint panel for the raw values: JA4, the older JA3, ECH status, the TCP row with JA4T and the HTTP/2 fingerprint.

SNI Encryption: What Encrypted Client Hello Hides and What It Doesn't

ParallaxGrain — Tue, 03 Nov 2026 14:00:00 +0000

HTTPS over TLS 1.3 encrypts the certificate, the URL path and the page. The site's name still goes out in plain text, in a field called Server Name Indication (SNI) inside the very first message, the ClientHello. Your ISP can read it, and so can a café's Wi-Fi or a corporate firewall. SNI encryption closes that gap, and Encrypted Client Hello (ECH) is the standard that does it: RFC 9849, published in March 2026.

ECH hides which site you asked for. It does not hide where the connection goes, or the DNS lookup that came before it.

How SNI encryption works in ECH

The browser builds two hellos. The inner one carries the real name and the real ALPN list (the protocols it offers, such as HTTP/2 and HTTP/3) and is encrypted with a public key the site published in DNS. The outer one travels in plain text with a stand-in name.

The browser asks DNS for the site's HTTPS record, a record type that describes how to connect. If the record has an ech parameter, it holds the public key and the stand-in name, called the public_name.
The browser encrypts the inner ClientHello to that key.
It sends the outer ClientHello with the public_name in the SNI field and the encrypted inner one attached as an extension.
The server decrypts the inner hello and finishes the handshake as the real site. If the key is stale or the server doesn't speak ECH, it answers as the public_name and, when it can, hands back fresh keys so the browser retries.

Sites behind the same provider that share a key and look alike on the wire form an anonymity set. An observer sees a connection to the provider and can't tell which of its sites it was.

Who sees what

What an ISP, a Wi-Fi owner or a firewall on the path can read:

What a network observer reads	No ECH, plain DNS	ECH, plain DNS	ECH, encrypted DNS
Site name in the SNI field	Readable	Hidden	Hidden
Real ALPN list	Readable	Hidden	Hidden
Site name in the DNS lookup	Readable	Readable	Hidden
Destination IP address	Readable	Readable	Readable
Provider's public_name	Not used	Readable	Readable
Packet sizes and timing	Readable	Readable	Readable
URL path, cookies, page content	Hidden	Hidden	Hidden

The DNS resolver sees every name it resolves in all three setups, and the destination can read the real name, so both always know.

What stays visible with ECH

The IP address. A connection has to reach a server, so the address is on the wire. When thousands of sites share a provider's addresses it says little. A site alone on its own address is identified by that address, and ECH adds nothing there.
The public_name. Every ECH site at a provider shows the same stand-in, such as cloudflare-ech.com on Cloudflare. It tells an observer which provider the connection goes to, and a fixed name is easy to match. In November 2024 Russia began blocking connections that carry an ECH extension together with that visible name. Browsers also send a decoy ECH extension to sites without ECH, so the extension alone gives nothing away; the name does.
Volume and timing. ECH pads the inner hello (the configuration carries a maximum_name_length for that) so its size doesn't hint at the name. The size and rhythm of the traffic after the handshake are another matter and remain visible.
The rest of the outer hello. Cipher suites, extensions and their order are in plain text, and a TLS fingerprint such as JA4 is built from fields like these. They describe the client software, not the site.

Encrypted Client Hello and DNS

The key for ECH lives in DNS, so DNS both delivers the key and leaks the name. With plain DNS, the lookup for the site and for its HTTPS record cross the network readable, which gives the name away before the handshake starts. A network that controls the answers can also delete the ech parameter. The browser then has no key and connects the old way, with the name in plain text. Once it holds a key, it doesn't quietly retry with a plain hello when the handshake fails, so a network that wants the name must remove the key beforehand or block the connection. Encrypted DNS (DoH, DoT or DoQ) closes the first two holes on the path, though the resolver you picked still sees every name.

ECH vs VPN

A VPN and ECH hide different things from different observers. A VPN tunnels all traffic, so the local network sees only the VPN server, and the VPN provider takes the observer's seat, seeing destination addresses plus any names in handshakes and DNS queries that aren't encrypted. ECH removes the name from the handshake, so that observer can't read it there, though the addresses remain. Together they split the job: the VPN hides the destination addresses from your ISP, and ECH hides the handshake name from the VPN provider.

Where ECH is switched on in 2026

Chrome has had ECH on by default since version 117 (September 2023), Firefox since October 2023.
Android 17 adds ECH at the platform level and pairs it with Private DNS, the system-wide encrypted DNS setting. Apps need a networking library that uses it: OkHttp 5.5.0 and later can enable it, the system HttpEngine follows in Android 17 QPR2 and WebView in a later release.
OpenSSL 4.0, released in April 2026, is the first OpenSSL release with ECH, so software that builds on it can start supporting ECH.
Cloudflare enables ECH by default on Free zones; other plans turn it on in the dashboard. Most domains that support ECH sit behind Cloudflare, so most of the anonymity set is one company's network.

What filters and firewalls do about ECH

A filter that matches on the SNI loses its input once the name is encrypted. Filtering by name still works at the DNS resolver, which sees every name. Where that doesn't fit, a network can answer HTTPS queries without an ech parameter, or not at all, so clients never get a key. Managed browsers can switch ECH off: Chrome has an enterprise policy for it, and Firefox stops using ECH when the resolver returns no answer for a canary domain. The last resort is decrypting the traffic at a TLS-intercepting proxy.

Check a site and your own connection

The ECH Checker looks up a domain's HTTPS record, reads the ech parameter and decodes the configuration, including the public_name that observers see. A domain with no ech parameter gives a browser no key to encrypt with, whatever the browser supports.
The ECH Status card on the Privacy & Trust Index reports whether the name of the site you visited was encrypted in your connection. When the name was hidden but your DNS still reveals it, the card says DNS STILL OPEN.
Browser switches and server settings are in the ECH setup guide.

Browser Fingerprinting Protection: Randomize, Blend In or Block

ParallaxGrain — Sat, 31 Oct 2026 05:58:53 +0000

A page can ask the browser which graphics card it runs on, through WebGL, the browser's 3D graphics interface. An unprotected browser answers with the exact model. Brave answers with one word, "Brave", for the vendor and the renderer alike. That is deliberate: Brave decided the model is too identifying to give out, which makes it the simplest case of browser fingerprinting protection.

A fingerprint works for a tracker only when it is distinctive (few other browsers match it) and stable (it survives from one session to the next). Defenses go after one or the other, and most browsers mix them.

A browser can make your fingerprint shared, shifting or unreadable. It can't make it disappear, because a page can't render without reading some of those values.

Three kinds of browser fingerprinting protection

Blend in. Many browsers report identical values, so the fingerprint stops being distinctive: it points to a crowd instead of a person. Tor Browser and Mullvad Browser are built on this.
Keep changing. The browser adds small random noise to what it returns, so the fingerprint is not stable: the same machine looks different to every site and again after a restart. Brave is built around this.
Block. The browser stops scripts that appear on lists of known fingerprinters, or refuses to return the data at all, so there is nothing to read. Firefox, Safari, Edge and DuckDuckGo lean on lists like this, and Tor Browser also withholds canvas image data.

Which move fits depends on the value. Canvas pixels and audio samples survive a nudge nobody can see. A name does not: a GPU model can only be replaced by something generic.

Brave fingerprinting protection: noise for pixels, one name for the GPU

Brave calls its noise farbling. Canvas readback, Web Audio output and WebGL values come back slightly altered, by an amount nobody notices on screen. The noise comes from a seed that is new every session and different for every site. Inside one site and one session the answers stay consistent, so pages keep working; across sites and across restarts they don't match. An embedded tracker doesn't get a seed of its own. It inherits the one of the page it sits on, so the same tracker reads different values on two sites and can't join the visits. Fingerprinting scripts typically hash many values into one ID, so changing a single input changes the whole hash.

For names, Brave blends in. In version 1.93, rolled out from August 2026 on desktop and Android, the WebGL vendor and renderer strings both come back as "Brave", the WebGPU adapter details are emptied, and the list of supported WebGL extensions gets noise, because that list differs by GPU and driver. Every Brave user presents the same graphics card, which makes a crowd, though the string also tells a site which browser it is talking to.

Firefox and Safari fingerprinting protection: some noise, some lists

Since Firefox 151 (May 2026), desktop Firefox changes the canvas image a script exports, differently in each browsing session, in every window. Its standard tracking protection also blocks the known fingerprinters. Private windows and Strict mode add more, including a coarse CPU core count. The pixel noise they are meant to add on top doesn't currently run next to the lighter mode, so a script that reads canvas pixels directly still gets the real ones. Tor-style uniformity (the resistFingerprinting preference) is an advanced setting, off by default.

Safari takes two routes. In Private Browsing it adds tiny noise to 2D canvas and WebGL readback and to Web Audio samples, and it reports the screen as the same size as the window; the same set can be turned on for every tab in Advanced settings. In normal windows, since Safari 26 (September 2025), known fingerprinting scripts can't reliably read screen size, CPU core count, speech voices, audio or 2D canvas, and can't store long-lived data. That layer works from a list; a script that isn't on it still reads a normal window.

Browser fingerprinting protection compared

Browser	Approach	What it changes	The catch
Brave	Randomize, plus one shared GPU name	Canvas, audio and WebGL values shift per site and session; GPU strings read "Brave"	Noise is best-effort
Firefox	Block, light randomization	Known fingerprinters blocked; exported canvas varies per session; private windows and Strict add a coarse core count	Pixels read directly stay real; uniform mode is off by default
Safari	Block, noise	Known scripts restricted in every window; noise on canvas, WebGL and audio in private windows	A script not on the list still reads normal windows
Tor Browser	Blend in	One user agent per OS family, window letterboxing, canvas extraction blocked	Users are grouped into fewer buckets, not made identical
Mullvad Browser	Blend in	Same techniques, no Tor network	Your IP stays visible without a VPN
LibreWolf	Blend in	resistFingerprinting on, WebGL off, language reported as en-US	The crowd is LibreWolf users only
DuckDuckGo	Block	Listed fingerprinting scripts blocked, listed APIs overridden	Covers what is on its lists
Edge	Block	Fingerprinters that also sit on another tracker list, at every level	Scripts only on the fingerprinting list still run
Chrome	Reduced User-Agent only	Less detail in the User-Agent string; canvas, GPU and audio values stay real	Incognito doesn't change that
Opera, Vivaldi	Tracker-blocker lists	Known trackers blocked	No fingerprint-specific protection documented

The table covers one question. What each browser also blocks, sends home, hides with a built-in VPN or does with AI is in the full comparison of 11 browsers.

When protection makes you stand out

Blending in works only where the crowd is big. A US English setting is common on most sites, yet on a small foreign-language site the same setting can single you out, and a browser can't know how many visitors resemble you on each site.

The same logic punishes rare setups. Brave dropped its Strict fingerprinting mode: it broke sites, and fewer than 0.5% of users ran it, a group small enough to stand out. Tor Browser doesn't let you choose which operating system you appear as, because any choice would make users more unique. Changing many settings, or stacking extensions that rewrite values, tends to make a browser rarer, not more private.

Randomization has the opposite limit. It is a best-effort defense against trackers working at web scale, and a determined attacker aiming at one person can try to filter the noise out.

What incognito and a VPN leave alone

A private window in Chrome leaves canvas and GPU values as they are. In Firefox and Safari it switches on the extra protections above. A VPN swaps the IP address and leaves every value measured inside the browser untouched. Below the browser, the first TCP packet still shows the operating system's network stack, whatever the user agent claims, and no browser setting edits it.

How to check what your browser really does

Open the Privacy & Trust Index and let the scan finish. Note the result on the Canvas Fingerprint card and the WebGL renderer under Graphics & Media Fingerprint. A stable canvas hash is shown there too.
Close and reopen the browser, or use a private window, and scan again. A hash that changed is being randomized. One that stayed the same is a stable ID.
Read the card. CANVAS LEAK means the drawing was identical every time and lowers the Privacy score. IDENTITY SHIFTING means it changed between reads, PROTECTED means light noise, CANVAS INTERCEPTED means a tool is handling it, CANVAS BLOCKED means the canvas is off. None of the five results lowers the Trust score.
Read the renderer string. A generic or empty value is protection; a string that names your actual GPU is public to every page.

A single scan can't measure how rare you are, because rarity depends on who else visits. The canvas leak guide explains each result and how the browsers above draw the line.

How to Identify AI Agents When Anyone Can Fake the User-Agent

ParallaxGrain — Thu, 29 Oct 2026 14:00:00 +0000

Your access log says ChatGPT. Or Claude, or Google-Agent. The line looks official, but the name in it is whatever the client chose to send, and any scraper can send the same one.

That used to be a headache for search engines and big publishers. Now AI agents compare prices and fill carts for real people, and every site with a firewall rule or a rate limit runs into it. Knowing how to identify AI agents comes down to one question: who sent this request, and can they prove it?

A User-Agent is what a bot says about itself. A signature is something it has to prove, with a key an impostor doesn't have.

Why AI agents are harder to identify than crawlers

Classic crawlers are the easy case. Googlebot crawls from Google's own addresses, and those addresses have hostnames that point back to Google. Agents break that pattern in three ways:

They act for a person, in real time. An agent opens a page because someone asked it to, and for user-triggered fetchers like ChatGPT-User, robots.txt rules may not apply.
They often drive a real browser. The request looks like Chrome from the TLS handshake to the last header, so the tricks that catch simple scripts see a browser.
They run on shared infrastructure. Plenty of agents work inside cloud browsers hosted by third-party platforms, so the IP address belongs to the platform and every other customer exits from the same pool.

The old ways to detect AI agents either can't see the agent at all, or can't tell it apart from an impostor on the same network.

Four ways to check a bot's identity, and what each can fake

Method	What it checks	Can an impostor fake it?	Works for agents on shared clouds?
User-Agent string	Text the client writes about itself	Yes, in seconds	No
Published IP ranges	The address is on the operator's list	Not from outside, but co-tenants on those IPs look identical	Poorly: the list names the platform, not the agent
Reverse DNS	The IP's hostname is the operator's and resolves back to it	No	Rarely: mostly search crawlers set this up
Signed request (Web Bot Auth)	A key published on the operator's domain signed the request	Not without the private key	Yes: the key travels with the agent

The forward half of the reverse DNS check is the part that matters. Anyone can set the reverse name of their own IP to googlebot.com, but only Google can make that name resolve back to it.

The first three methods infer identity from something next to the request: a string inside it, the address behind it, a DNS record somewhere else. A signature puts the proof inside the request itself.

How signed requests work

Web Bot Auth is built on HTTP Message Signatures, RFC 9421, a finished IETF standard since February 2024. The part that tells bots how to use it is still a set of drafts in an IETF working group, so details can change. The flow:

The operator creates a key pair. In practice that's Ed25519, a small, fast elliptic-curve key. The private half stays with the operator.
It publishes the public half in a key directory: a small JSON file at a fixed address on its own domain, /.well-known/http-message-signatures-directory. The file is served over HTTPS, so the domain's TLS certificate vouches for who published those keys.
The agent adds three headers to every request. Signature-Agent says where its keys live. Signature-Input lists what was signed: at least the host being requested, plus a creation time, an expiry time, the key's ID and the tag web-bot-auth, which marks it as a bot signature. Signature carries the signature itself.
The site checks. It reads Signature-Agent, fetches the directory (once, then from cache, even for an agent it has never seen), picks the key by its ID, rebuilds the signed text from the request and verifies the signature. With the keys cached, that's one signature check per request.

Two details make this hard to abuse. The signature covers the host, so a copy captured on one site won't verify on another. And it expires. The drafts recommend a lifetime of no more than 24 hours, so a stolen copy goes stale on its own.

What a valid signature proves, and what it doesn't

A valid signature tells you two things: the request was signed by someone holding a key that the domain in Signature-Agent publishes, and it was signed inside its validity window.

It doesn't tell you:

that the agent is harmless, or allowed to do what it's doing. Good bot vs bad bot is still your call, made on behavior;
that the request is fresh. A copied signature can be replayed until it expires, unless the site also demands a one-time value (a nonce) and remembers the ones it has seen;
who the human behind the agent is. The protocol doesn't authenticate users at all.

A missing signature proves nothing either. Your own browser doesn't sign requests, and neither does most legitimate software.

One rule follows from all of this. Attach your policy to the domain whose key verified the request, never to whatever the Signature-Agent header says. The header only tells you where to look for the key.

Who signs today, and who checks

Adoption is early, and it changes month to month:

The cloud browser behind ChatGPT's agent features signs its outbound requests, with Signature-Agent set to chatgpt.com.
Google signs some Google-Agent requests, as agent.bot.goog. The rollout is experimental and partial, so IP and reverse DNS checks stay as the fallback.
Classic crawlers such as GPTBot are still verified by their published IP lists.
On the checking side, Cloudflare, AWS WAF, Akamai and Vercel verify these signatures for their customers. Cloudflare accepts a valid signature as one of three ways a verified bot can identify itself, next to an IP list and reverse DNS.

How to identify AI agents on your site

Stop letting the User-Agent open doors on its own. A rule that waves through anything calling itself ChatGPT waves through every scraper that copies the name, and faking a User-Agent takes one line of config.
Check what your CDN or WAF already does. Behind one of the services above, signed agents may already be verified and labeled for you. Point your rules at that label, not at the string.
Log the three signature headers. Default access log formats skip them, and without them you can't check a request after the fact.
Keep IP lists and reverse DNS for everything that doesn't sign, and refresh the lists on a schedule.
Sort requests into three groups: verified (policy goes to the signing domain), signed but failed (suspicious, often just a misconfigured client) and unsigned (unknown, which is different from guilty).
Keep your rate limits. A verified agent hitting your search endpoint 50 times a second is still hitting it 50 times a second.

To see what a real signed request proves, paste one, headers included, into the Agent Verifier. It shows what the signature proved and what the key directory publishes, and when something fails, it names the fault and the one change that fixes it. Nothing is stored, and an expired signature works too, checked as of the moment it was made.

If you build agents: sign, then check from the outside

On rented cloud IPs, a signature is the one identity signal that doesn't depend on the neighbors. The catch is that a broken one fails silently. From the client side, a malformed signature looks exactly like an agent the site has never heard of. The usual suspects:

signed text built one character differently from what the verifier rebuilds, like missing quotes or an extra line break;
a key directory your own CDN refuses to serve, because a bot rule blocks the verifier;
a key ID that's a short label instead of the key's thumbprint;
a redirect between the bare domain and www, which verifiers following the draft won't follow.

All four look fine from your own machine. Paste a request your agent really sent into the Agent Verifier to see which one you hit, or follow the implementation guide step by step: key, directory, signature, check. Your agent can also check itself. Connect the packet.guru MCP server and it finds a self-check tool that takes no arguments and reports how its own request arrives, signed or not.

What a VPN Doesn't Hide: 4 Things Websites Still See

ParallaxGrain — Tue, 27 Oct 2026 14:00:00 +0000

A VPN does one job, and does it well. It wraps your traffic in an encrypted tunnel to its own server. Your Wi-Fi and your internet provider see only a connection to that server, and websites see the server's IP address instead of yours.

That's the whole job. What a VPN doesn't hide is everything your device says about itself on the way in, plus anything that slips around the tunnel. You can be tracked with a VPN on, and a site can often work out roughly where you really are.

A VPN changes where your traffic comes from. It doesn't change what your device says about itself.

What a VPN doesn't hide, at a glance

What a website sees	VPN off	VPN on
IP address	Your provider's	The VPN server's
Location from the IP	Your city or region	The server's country
DNS resolver	Your provider's	The VPN's, unless DNS leaks
Address found by WebRTC	Yours	The VPN's, unless it leaks
Time zone and languages	Yours	Still yours
Browser fingerprint	Yours	Still yours
Cookies and logged-in accounts	Yours	Still yours

The first two rows are what you pay for. The rest is where people get caught.

1. Your DNS lookups

Before your browser opens a site, it asks for the site's numeric address. That lookup is DNS, the internet's phone book, and the server that answers is a resolver. A VPN should route these questions to its own resolver, inside the tunnel. When they go to your provider's resolver instead, that's a DNS leak: your provider sees the name of every site you open, and any site that checks sees your lookups and your connection coming from two different networks.

Sites spot it with a neat trick: the page makes your browser look up a random, never-used name under a domain the site controls. No resolver has it cached, so the question travels all the way to the site's own name server, which records who asked. Your home provider's resolver next to a VPN's IP means the leak is real.

The usual causes:

the VPN app doesn't set its own DNS server;
Windows, when a lookup times out, can resend it on every network interface, including the one outside the tunnel;
your router hands out IPv6 DNS servers, and the VPN only tunnels IPv4.

Most VPN apps have a DNS leak protection setting. Turn it on.

2. Your real IP, through WebRTC and IPv6

WebRTC is the part of the browser behind video calls and direct file transfers. To connect two browsers directly, it asks a STUN server one question: what address do you see me coming from? The answer is your public IP, and a page can trigger the question without any permission prompt.

With a full-tunnel VPN, the STUN server sees the VPN's address, and nothing new leaks. Your real address gets out in three setups:

A browser "VPN" extension. In Chrome and Firefox it works as a proxy, and unless the extension blocks it, WebRTC sends its STUN request over UDP, straight past the proxy.
A split tunnel that lets the browser, or all UDP traffic, bypass the VPN.
A VPN that only carries IPv4. If your provider also gives you IPv6, that traffic still goes out through your router, so any site you reach over IPv6 sees your real address, and WebRTC can list it next to the VPN's.

Your local address, the 192.168.x.x kind, is mostly safe now: Chrome has replaced it with a random .local name since version 76, unless the site already has camera or microphone access.

3. Your clock and your languages

Any page can read your device's time zone with one line of JavaScript, no permission needed. It comes back as a full zone name, like Europe/Warsaw or America/Chicago, which usually points to one country. The server looks up the time zone of your IP in a geolocation database and compares the two.

A VPN can't touch this. The time zone is a setting on your device, and no VPN protocol carries or rewrites it. Your languages come along unchanged too: the browser lists them in the Accept-Language header, a line of metadata attached to every request.

A laptop set to Europe/Warsaw, with Polish as its first language, behind an IP in a New York data center tells a site two things: the user is probably in Poland, and something sits in between. That's a timezone mismatch. Travellers and company VPNs produce it every day, so on its own it rarely gets anyone blocked. Next to other warning signs, it can mean a CAPTCHA or an extra login check.

The fix is boring: set your device's time zone to match the VPN server, or pick a server in your own time zone. Extensions that fake the zone tend to miss one of the several places a page can read it from, and a browser that reports two zones at once looks worse than an honest mismatch.

This is also why a VPN often isn't hiding your location on maps and delivery sites. A site you've allowed to use your location gets it from the device itself, through GPS or the Wi-Fi networks around you, and a VPN changes neither.

4. Your browser fingerprint and your accounts

Your browser describes itself to every site: screen size, installed fonts, graphics card, CPU cores, and the tiny differences in how your hardware draws an image on an invisible canvas. Together these values form a browser fingerprint, an ID that needs no cookies. Every value is measured on your device, so it stays the same when your IP changes.

Stored data comes along too. Cookies set yesterday on your home connection are still in the browser today, and the moment you log in, the site knows exactly who you are, whatever country your IP is in.

Does a VPN hide your identity, then, or make you anonymous? Not by itself. It hides your address from websites and your browsing from your provider. Your identity lives in the browser and in your accounts, and those don't change inside a tunnel.

The same four things, in a YouTube Short:

How websites detect a VPN anyway

A VPN that leaks nothing is still usually easy to spot, because sites add up clues:

The address. VPN servers usually run in data centers. Every IP belongs to a network with an ASN, the number that identifies who owns it, and IP databases label hosting networks and known VPN ranges.
The first packet. A VPN forwards your device's own packets, so your operating system still shows through. That packet also states the maximum segment size (MSS), the largest chunk of data your device accepts at once. Tunnel headers eat into it, so the MSS comes out smaller than on a plain home line, in a range typical of tunnels.
Proxies leave the opposite mark. A proxy opens its own connection to the site, so the site reads the proxy server's operating system instead of yours. A browser that says Windows over a packet that looks like Linux is the classic proxy pattern.
Any of the four leaks above.

Detection tells a site that you use a VPN, not who you are. For a bank or a streaming service, that alone can be reason enough for an extra check or a block.

How to check what your VPN leaves exposed

The Privacy & Trust Index on packet.guru is a browser fingerprint test and a leak test in one. It shows what a website sees about your connection and your browser, card by card.

Turn the VPN off, open packet.guru/whoami and let the scan finish.
Turn the VPN on, reload the page and wait for the new scan.
Compare the cards:
- IP Reputation should switch to VPN / PROXY or DATACENTER, and Network Details should show no second address from your home provider.
- DNS Privacy should not say DNS LEAK.
- WebRTC Status should read SAFE or PUBLIC IP MATCH, not LEAK DETECTED.
- Regional Integrity shows TIMEZONE MISMATCH if your clock still points home.
Read the two scores. Privacy is how hidden you are, Trust is how genuine you look to anti-fraud systems. A VPN can raise the first and lower the second.

The canvas, audio and speech-voice fingerprints usually come out the same in both runs. That's the part the VPN never touched.

For the full set of checks, including a kill switch test for the moment your VPN drops, see the VPN test guide.

How Websites Identify Your Device Without Cookies

ParallaxGrain — Sun, 25 Oct 2026 19:30:35 +0000

Clearing cookies feels like starting over. For a lot of sites it isn't. They never needed to store anything on your device to recognize you, because your browser describes itself in enough detail on every visit that the description works as an ID.

This is browser fingerprinting, and it's how many websites identify your device without cookies.

A fingerprint isn't stored on your device. There is nothing to delete.

The three layers of a fingerprint

A fingerprint is built from three layers. Each one on its own says little. Together they point to one device.

Layer	Signal	What it reveals
Connection	IP address	Your provider and rough location
Connection	TLS handshake (JA4)	Which browser or tool really connected
Connection	First TCP packet	Your operating system family
Headers	User-Agent	Browser, version and OS
Headers	Accept-Language	Your preferred languages
Headers	Client hints (Chromium)	Exact build, CPU architecture, phone model
Script	Screen	Resolution, pixel density, taskbar size
Script	Time zone	Your region, checked against your IP
Script	Fonts	Software you have installed
Script	WebGL	Your graphics card model
Script	Canvas and audio	How your hardware draws images and processes sound
Script	Hardware	CPU cores, memory, touch support
Script	Speech voices	Your OS and language packs

What your browser tells every website

The header layer arrives with every request, before any script on the page runs. Your browser sends its User-Agent, a short line of text with the browser name, version and operating system, and its language preferences. Chrome and other Chromium browsers add client hints on request, down to the exact build and, on Android, the phone model.

This is passive fingerprinting. The site only has to write down what your browser already sends.

What a script on the page can measure

Active fingerprinting goes further. A script asks the browser questions, and the browser answers, because ordinary websites need the same answers to work. A few examples show how much leaks:

The gap between your full screen and the usable area gives away the size of your taskbar or dock.
Your time zone gets compared with your IP address. A browser set to Tokyo time behind a German IP is unusual, and unusual is exactly what trackers and fraud systems look for.
A page can't ask for a list of your fonts, so it tries a few hundred font names and measures how wide the text comes out. Office suites and design apps install fonts most people don't have.
Through WebGL, the part of the browser that draws 3D graphics, a page can usually read the exact GPU model.

The strongest signal is the way your computer draws. In canvas fingerprinting, the page draws text and shapes on an invisible canvas and reads the pixels back. The result depends on your operating system, fonts, graphics driver and GPU, so the same machine produces the same image every time, down to the pixel. Audio works the same way: a short sound is processed inside the browser with nothing played out loud, and tiny differences in the result are measured.

Why the combination identifies you

Hardly any of these values is rare on its own. Millions of people run Chrome on Windows with English settings and a 1920×1080 screen. Add the time zone, the fonts, the GPU and the canvas result, and that crowd shrinks fast.

A tracker needs exactly two things from the combination:

Distinctive. Few other browsers share it.
Stable. It stays the same between visits.

Stability doesn't have to be perfect. When a browser update changes a couple of values, the rest stay put, and the new fingerprint is easy to match to the old one. Most defenses are built on the opposite idea: a value that changes on every visit is useless for tracking, however rare it is.

Fingerprints below the browser

The connection layer is the one most people never hear about. When your browser opens an HTTPS connection, its very first message lists the encryption methods it supports. A format called JA4 turns that list into a short code that looks different for Chrome, Firefox, Safari and a Python script. One layer lower, the first network packet carries values set by your operating system, which point to Windows, macOS, Linux or iOS regardless of what the browser says.

No browser setting changes either one. Servers compare both with what the browser claims to be, so an "iPhone" that connects with the handshake of a Python script stands out right away.

Real visitor vs. headless bot

Bot detection relies on exactly these checks. Here is how an ordinary laptop compares with a headless Chrome running on a server, the kind scrapers use:

Signal	Ordinary laptop	Headless Chrome on a server
User-Agent	Chrome on Windows or macOS	Contains "HeadlessChrome"
Screen	1920×1080 with a taskbar	800×600, no taskbar
Graphics card	Intel, AMD, NVIDIA or Apple	SwiftShader, a software renderer
Speech voices	Several system voices	None
IP address	Home or mobile provider	Datacenter

And this is what the packet.guru scan reports for that headless Chrome:

Trust drops to 45 out of 100: automation detected, a datacenter IP, and a clock that doesn't match the IP's region. The TLS and TCP fingerprints pass, because this really is Chrome on Linux. That's the point. These systems care less about how unique you are than about whether your details agree with each other.

Who uses fingerprinting

Banks and online shops, against account takeover. A correct password typed on a device they have never seen can trigger an extra check.
Bot detection, to catch automated browsers like the one above.
Advertising, to link your visits across sites even when you block or delete cookies. Since February 2025, Google no longer forbids advertisers who use its ad products from fingerprinting, so expect more of it. In the EU, fingerprinting for ads and tracking needs your consent, the same as cookies.

What doesn't protect you

What people try	What it changes	Your fingerprint
Clearing cookies	Removes stored identifiers	Unchanged
VPN	Your IP address	Unchanged, and a badly configured VPN can leak your real IP
Incognito mode	What gets saved on your device	Mostly unchanged
More privacy extensions	A few values here and there	Often more unique

Extensions deserve a closer look. Every extension that changes what pages see is a trait of its own, and changing one value while leaving the rest creates contradictions, like a Windows User-Agent on top of a Mac's graphics hardware. To a fraud system that looks like forgery.

Incognito is the most common false hope. Here's the short version:

How to avoid browser fingerprinting

The best choice is a browser with protection built in, used with its default settings.

Browser	How it protects you	Trade-off
Tor Browser	Makes all users look alike	Strongest, but slower and some sites break
Brave	Random changes to canvas, WebGL and audio, per site and session	On by default
Safari	Random changes to canvas, WebGL and audio	Strongest in private browsing
Firefox	Blocks known fingerprinting scripts, limits more values	Full protection in private windows and strict mode
Chrome	Blocks known fingerprinting scripts in Incognito	Little protection in regular windows

Whatever you use:

keep extensions to a minimum;
don't change your User-Agent by hand;
switch protection off only for the one site that breaks, not globally.

Check your browser in two minutes

Open packet.guru/whoami and run the scan.
Look at the two scores: Privacy, how hidden you are, and Trust, how genuine you look to a fraud system. The cards below show the reason behind every point.
Open a private window or restart the browser, and scan again.
Compare. Values that changed between the two runs are being randomized. Values that stayed the same can be used to recognize you.

Browser-by-browser defenses are covered in the guide to browser fingerprinting on the packet.guru blog.