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 is OBSOLETE TLS 1.3 #

TLS Session Resumption via identifiers and tickets 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.

The client sends one or more PSK identities as opaque blobs of data. They can be database lookup keys (similar to Session IDs), 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.

Perfect Forward Secrecy can be maintained by limiting the lifetime of PSK identities sensibly. Clients and servers may also choose an ECDHE Cipher Suite for PSK handshakes to provide Perfect Forward Secrecy for every connection, not just the whole session.

Authentication #

As in 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.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-6) was last changed on 02-Mar-2017 15:38 by jim