session_ticket
session_ticket allows resuming a TLS 1.2 session with a ticket from an earlier connection. Half the measured clients send it.
What it is
session_ticket (extension 35) is defined in RFC 5077 for TLS 1.2. The server can hand the client an encrypted ticket that holds the session state. On the next connection the client presents the ticket in this extension, and the server can resume the session without a full handshake.
Tickets move the session cache from the server to the client, which makes resumption easy for large server farms. The price is that the ticket encryption key becomes very sensitive: if it leaks, all sessions resumed with it can be decrypted, which weakens forward secrecy unless the key is rotated often.
An empty session_ticket extension just means the client supports tickets. TLS 1.3 replaced this mechanism with its own PSK-based resumption.
Many clients send it on every connection, empty on the first one and with a ticket on later ones.
Who sends it
Measured on 2026-10-25 against our own test server: sent by 7 of 12 clients. Position counts from 1 and ignores GREASE values.
Why it matters for fingerprinting
Chrome, curl_cffi, both curl-impersonate profiles, httpx and Node.js fetch send it. curl on macOS and Debian, Python requests, Go net/http and Guzzle do not send it in our measurements. Python requests and httpx use the same TLS library but differ here, which is one of the details that gives them different JA3 values.
Check whether your client sends it
Open the test from your browser, or call it from your script, and look for session_ticket in the TLS details.
Run the TLS fingerprint test