SSL session tickets vs session ids

Question

To improve SSL handshake performance for not retaining(short) connections there are two separate features known widely:

• TLS session ids
• TLS session ticket

Answer 1

When the server sends the “Server Hello” message, it can include a session identifier. The client should store it and present it in the “Client Hello” message of the next session. If the server finds the corresponding session in its cache and accepts to resume the session, it will send back the same session identifier and will continue with the abbreviated SSL handshake. Otherwise, it will issue a new session identifier and switch to a full handshake. This mechanism is detailed in RFC 5246. It is the most common mechanism because it exists since earlier versions of SSL.

In the last exchange of a full SSL handshake, the server can include a “New Session Ticket” message (not represented in the handshake described in the picture) which will contain the complete session state (including the master secret negotiated between the client and the server and the cipher suite used). Therefore, this state is encrypted and integrity-protected by a key known only by the server. This opaque datum is known as a session ticket. The details lie in RFC 5077 which supersedes RFC 4507.

The ticket mechanism is a TLS extension. The client can advertise its support by sending an empty “Session Ticket” extension in the “Client Hello” message. The server will answer with an empty “Session Ticket” extension in its “Server Hello” message if it supports it. If one of them does not support this extension, they can fallback to the session identifier mechanism built into SSL.

RFC 5077 identifies situations where tickets are desirable over session identifiers. The main improvement is to avoid the need to maintain a server-side session cache since the whole session state is remembered by the client, not the server. A session cache can be costly in terms of memory, and can be difficult to share between multiple hosts when requests are load-balanced across servers.