OpenSSL session cache concurrency behavior with session IDs and tickets

Question

OpenSSL provides TLS session resumption via server-side session cache and via Session Tickets per RFC 5077. The documented capability aims to reduce handshake latency for returning clients by reusing session state. Under concurrent connection loads, the behavior of the session cache becomes relevant for performance design.

Server-side caching stores session state in memory for rapid lookup, while session tickets move state to the client and remove server lookups. The documented limits for cache size, locking, and eviction under high concurrency are not clearly specified, and implementation-specific variance is noted for eviction policies.

What limits are documented for the default in-memory session cache under concurrent TLS handshakes? Is session cache locking documented as affecting handshake latency under concurrent requests? Is the eviction policy for session IDs configurable and documented compared with session tickets?

Muntasir · Answer

Likely explanationThe default SSL_SESSION in‑memory cache has no publicly documented maximum capacity; it grows with available memory and internal hash‑table mechanics. Under high parallel handshake loads, the cache is protected by internal mutexes, and lock contention can add measurable latency to each handshake, especially on multi‑core servers.Confirmed factsNo size cap is exposed through SSL_CTX or any public API.Concurrent cache access uses process‑wide mutexes; contention depends on OpenSSL version, platform, and connection pattern.Eviction policy for stale session IDs is not configurable via the public API; implementation follows version‑dependent internal LRU/time‑based rules.Session tickets (RFC 5077) move state to the client, completely bypassing the server‑side cache lookup and its associated locking overhead for resumed connections.Steps to investigateRun openssl version -a to confirm the exact OpenSSL release and platform.Use the CRYPTO_set_id_callback and CRYPTO_set_lock_callback hooks (or strace/ltrace) to observe lock acquisition during handshakes.Measure handshake latency with openssl s_client across parallel processes, comparing runs with and without ticket usage (‑ticket flag or SSL_SESSION_set_ticket).Profile cache occupancy and eviction order via an instrumented build or external tracing to confirm internal LRU/time behaviour.Diagnostic requestTo tailor further recommendations, please specify the OpenSSL version and whether session tickets are enabled in your deployment.

OpenSSL session cache concurrency behavior with session IDs and tickets

1 answer

Likely explanation

Confirmed facts

Steps to investigate

Diagnostic request

Your perspective belongs here.

0 question comments