What TLS Session Resumption Reveals About a Client

Session resumption exists to make repeat connections cheaper. In doing so it creates client-held state and a set of behaviours that differ between implementations, both of which are visible to the server.

Resumption avoids a full handshake

A complete handshake involves key exchange and certificate verification, which costs round trips and computation. Resumption reuses secrets established earlier to skip most of that work.

The saving is meaningful on connections where latency dominates, which is most of the web. Browsers therefore resume aggressively wherever a server permits it.

Because resumption is an optimisation, servers can decline it and force a full handshake. What a client does when refused is itself variable.

Tickets and session identifiers are client-held state

The server issues an opaque blob that encodes enough to re-derive the session. The client stores it and presents it on the next connection.

That blob is state the server created, which makes it closer to a cookie than to a fingerprint. It lives below the application layer, outside the browser's ordinary storage controls.

Browsers have responded by partitioning this state alongside other storage, so a ticket obtained while visiting one site is not offered while visiting another.

Resumption behaviour differs by implementation

Clients differ in how many tickets they retain, how quickly they use one, and whether they attempt resumption in parallel with a full handshake.

These are library-level decisions rather than configuration, so they follow the implementation rather than any setting a user chose. Two clients claiming to be the same browser may resume differently.

Automation stacks built on general-purpose network libraries are visible here, because their defaults were chosen for servers rather than to match a browser.

Ticket reuse can link visits

If a client presents the same ticket on two connections, the server knows those connections came from the same client. That link needs no cookie and no fingerprint.

The linkage is bounded by the ticket's lifetime and by whether the client reuses tickets at all. Modern clients generally use a ticket once and discard it.

Single-use tickets remove most of the linking capability while keeping the performance benefit, which is why they became the default behaviour.

Why servers limit ticket lifetime

A long-lived ticket represents key material sitting outside the server's control, so lifetimes are kept short for security reasons independent of privacy.

Short lifetimes also limit how long a resumption-based link can persist, which is a useful side effect rather than the original motivation.