Overview#There are two primary mechanisms for TLS Session Resumption.
Both of these methods only allow TLS Session Resumption using the cryptographic parameters (Cipher Suites) established by the original handshake. This creates the opportunity for an attack in which the attacker who can intercept a user-agent's transport layer connection can inject traffic of his own as a prefix to the user-agent's interaction with the server. The Transport Layer Security (TLS) Renegotiation Indication Extension allows for Renegotiation of the Cipher Suite.
Session Tickets#Transport Layer Security (TLS) Session Resumption without Server-Side State describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state.
Session Identifiers#In RFC 5246 TLS 1.2 Appendix-F.1.4, states:
When a connection is established by resuming a session, new ClientHello.random and ServerHello.random values are hashed with the session's Master Secret. Provided that the Master Secret has not been compromised and that the secure hash operations used to produce the encryption keys and MAC keys are secure, the connection should be secure and effectively independent from previous connections.
Attackers cannot use known encryption keys or MAC secrets to compromise the Master Secret without breaking the secure hash operations.
Sessions cannot be resumed unless both the client and server agree.
If either party suspects that the session may have been compromised, or that certificates may have expired or been revoked, it should force a TLS Full Handshake. An upper limit of 24 hours is suggested for session ID lifetimes, since an attacker who obtains a Master Secret may be able to impersonate the compromised party until the corresponding session ID is retired. Applications that may be run in relatively insecure environments should not write session IDs to stable storage.
TLS Session Resumption TLS 1.3 uses 0-RTT Handshakes#TLS Session Resumption via Session Tickets and Session Identifiers is OBSOLETE in TLS 1.3. Both methods are replaced by a Pre-Shared Key (PSK) mode. A PSK is established on a previous connection after the TLS Handshake is completed, and can then be presented by the client on the next visit.
Once a TLS 1.3 TLS Full Handshake has completed, the server can send to the client a PSK identity that corresponds to a unique key derived from the initial handshake (see Section 4.6.1). The client can then use that PSK identity in future handshakes to negotiate the use of the associated PSK. If the server accepts the PSK, then the security context of the new connection is cryptographically tied to the original connection and the key derived from the initial handshake is used to bootstrap the cryptographic state instead of a full handshake.
The client sends one or more PSK identities as opaque blobs of data. They can be database lookup keys (similar to Session Identifiers), or self-encrypted and self-authenticated values (similar to Session Tickets). If the server accepts one of the given PSK identities it replies with the one it selected. The KeyShare extension is sent to allow servers to ignore PSKs and fall back to a TLS Full Handshake.
PSKs can be used with (EC)DHE key exchange in order to provide Perfect Forward Secrecy in combination with shared keys, or can be used alone, at the cost of losing Perfect Forward Secrecy for the application data.TLS 1.2, the client’s and server’s authentication states are retained and both parties do not need to exchange and verify certificates again. A regular PSK handshake initiating a new session, instead of resuming, omits certificates completely.
Session resumption still allows significantly faster handshakes when using RSA certificates and can prevent user-facing client authentication dialogs on subsequent connections. However, the fact that it requires a single round-trip just like a full handshake might make it less appealing, especially if you have an ECDSA or EdDSA certificate and do not require client authentication.