Why Security Software Alters Your TLS Handshake

A browser's handshake is one of the more reliable identifiers available to a server, right up until something on the machine intercepts the connection. Interception is common, and it replaces the browser's signature with the intercepting product's own.

Interception requires terminating the connection

To inspect encrypted traffic, a product must decrypt it, which means becoming one endpoint of the connection rather than observing it in passing.

The software installs a certificate authority the machine trusts, then presents certificates it generates for each site the browser requests. The browser accepts them because the authority is trusted locally.

A second connection is opened onward to the real server, and it is that second connection whose handshake the server actually sees.

The onward connection uses the product's stack

Security products build on general-purpose networking libraries rather than embedding a browser engine, so the outbound handshake reflects that library's defaults.

Cipher preferences, extension ordering and supported protocol versions all follow the library rather than the browser, producing a signature that has nothing in common with the browser the user is running.

Since a given product ships the same library across its installed base, the resulting signature is uniform across every machine running it, which makes it recognisable but not attributable to any user.

Consistency checks break in a specific way

Detection frequently compares what the connection suggests against what the application layer claims. Interception guarantees these disagree, because they now describe two different pieces of software.

That mismatch is one of the more heavily weighted indicators in many systems, since it is a reliable marker of a client that is not what it says it is.

Applied to an ordinary employee behind corporate inspection, the same indicator fires just as strongly, and nothing in the observation distinguishes the two cases.

Capability degradation is a side effect

Intercepting products often support fewer protocol features than current browsers, so connections through them fall back to older versions or lose newer transport options entirely.

Falling back is itself unusual for a current browser, adding a second suspicious property on top of the mismatched signature.

Performance suffers too, and the slower connection changes timing characteristics that some systems interpret as a slow or distant client.

Recognition is the practical mitigation

Signatures of widely deployed security products are well known and can be classified as such rather than as unknown clients, which changes the interpretation of the mismatch.

Where interception is recognised, the sensible response is to discount connection-level evidence and weight application behaviour and account history more heavily, because the connection layer is genuinely uninformative about the user in that case.