TLS Sessions and Resumption
A TLS session represents a secure communication context established between a client and a server. It includes shared secret values such as symmetric encryption keys and MAC secrets, which allow the peers to communicate efficiently after the initial handshake. Reusing an existing session, rather than negotiating a new one, avoids repeating the computationally expensive asymmetric cryptographic operations required during the handshake.
Session Resumption Mechanisms
Different TLS versions use different mechanisms for session resumption:
- Session IDs — Introduced in SSL 2.0 and used through TLS 1.2. They allow a client to present a previously issued session identifier to resume a connection. However, they require the server to maintain state in a session cache, which complicates scaling across clusters. Session IDs are now considered obsolete, and are not supported in TLS 1.3.
- Session tickets — Introduced in TLS 1.0 (RFC 4507, later RFC 5077) and supported in TLS 1.0–1.2 as well as in TLS 1.3. They shift the storage of session state to the client, removing the need for a server-side cache and making them better suited for distributed systems.
- TLS 1.3 — Relies exclusively on session tickets and extends their functionality with 0-RTT resumption, which further reduces latency.
The Role of sessiond
sessiond is designed specifically for environments that still use session IDs. It allows a cluster of SSL/TLS servers to share their session caches, preventing each node in the cluster from negotiating a separate session. This improves both performance and scalability when session IDs are in use.
However, because modern TLS (1.3 and later) no longer supports session IDs, sessiond is only relevant for legacy deployments that continue to rely on TLS 1.2 or earlier.
Configuration
sessiond accepts a port number as a parameter; the default is 54321.
The session timeout is currently hardcoded to 200 ms, which is a reasonable value to ensure uninterrupted operation in case of a sessiond server failure or a lost packet.
Security Considerations
Traffic between stunnel and sessiond is not encrypted, as the network infrastructure within a cluster is generally considered trusted.
Infrastructure security requirements:
- The sessiond port must not be accessible from untrusted networks.
- Network traffic between stunnel and sessiond must be accessible only to trusted personnel.
Best Practices
For new deployments, TLS 1.3 with session tickets is the recommended approach. Session tickets eliminate the need for a shared session cache and simplify scaling in clustered environments. They also provide better long-term support and security compared to legacy session ID mechanisms.
sessiond should only be used when compatibility with older TLS versions (TLS 1.2 or earlier) is required.
