Session caching

The SSLv2, SSLv3, TLSv1, TLSv1.1, and TLSv1.2 protocols can cache session information based on the TLS Session ID (SID). TLS connections can request that a previous session be resumed. When session information is found in the cache, connections can use the TLS abbreviated handshake, which requires less processing.

In a similar manner, the TLSv1.3 protocol can cache session information based on a session ticket. TLS connections can request that a previous session be resumed. When session information is found in the cache, connections can use an abbreviated handshake which avoids public key encryption.

The number of SIDs or session tickets cached, the length of time that a SID or session ticket is held in the cache, and whether SIDs or session tickets in the cache are available across the sysplex can be configured using the TTLSGskAdvancedParms statement.

Session ticket generation and caching for TLS Version 1.3 can be enabled for the client and server using the TTLSGskAdvancedParms statement. The maximum size of the session ticket accepted by the client, the algorithm used by the server to encrypt the session ticket, the number of session tickets that the server sends after an initial handshake completes, and the maximum time for which a session ticket is valid for session resumption can also be configured using the TTLSGskAdvancedParms statement.

For sysplex caching of session IDs or session tickets, the GSKSRVR must be started.

For additional information on session caching, see Session ID (SID) and session ticket cache and SSL started task in z/OS Cryptographic Services System SSL Programming.