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.

Answer 2

With session-ids, the server needs to keep track of previous sessions that could be continued at some point in time. This results in some extra work that the server has to do.

The session-ticket, in contrast, is not an identifier but the session data encrypted by the server (and only the server can decrypt it). When a client want so continue a session, it still knows the pre-master secret but the server does not anymore. So the client sends the session-ticket to the server and only the server is able to decrypt its content. Any information required to continue the session is included in there, so the server can resume the session without keeping any information. All the additional load is done on the client (by keeping the pre-master secret and the session-ticket).

Answer 3

You only need session IDs in this situation, and they are built in to most SSL implementations, unlike RFC 5077 ticketing, which is still a TLS extension.