How do TLS session tickets affect load balancing and session affinity?

1 What are TLS session tickets and session IDs?

TLS session tickets and session IDs are both ways of storing and retrieving the cryptographic parameters of a TLS session, such as the encryption keys, the cipher suite, and the protocol version. The difference is that session IDs are stored on the server side, while session tickets are stored on the client side. When a client wants to resume a TLS session, it can send either a session ID or a session ticket to the server, and the server can use them to restore the session state and avoid a full handshake.

2 How do TLS session tickets and session IDs affect load balancing?

Load balancing is the process of distributing the incoming requests among multiple servers or instances, to optimize the performance, availability, and scalability of your web application. Load balancing can be done at different layers of the network stack, such as the transport layer (TCP), the application layer (HTTP), or the presentation layer (TLS). Depending on the layer and the method of load balancing, TLS session tickets and session IDs can have different impacts. For example, if you use TCP-based load balancing, you can use either session tickets or session IDs, as long as the load balancer can forward the requests to the same server that handled the previous session. However, if you use HTTP-based load balancing, you may need to use session tickets, as session IDs may not be recognized by different servers behind the load balancer.

3 How do TLS session tickets and session IDs affect session affinity?

Session affinity is the property of maintaining the connection between a client and a specific server or instance, for the duration of a web session. Session affinity can be useful for applications that rely on stateful information, such as user preferences, shopping carts, or authentication tokens. Session affinity can be achieved by different methods, such as using cookies, source IP addresses, or TLS parameters. TLS session tickets and session IDs can both be used to implement session affinity, as they can identify the client and the server that established a TLS session. However, session tickets may offer more flexibility and security than session IDs, as they can be encrypted, rotated, and refreshed by the client.

4 What are the advantages of using TLS session tickets?

Using TLS session tickets can have several benefits for your web application, such as faster and more efficient TLS session resumption, reduced server-side memory and storage requirements, improved load balancing and scalability, and enhanced session affinity and security. This is because the client does not need to contact the server to retrieve the session state, nor does it need to store or manage session IDs. Furthermore, the client can resume a TLS session with any server that supports the same cipher suite and protocol version, without relying on a central database or cache of session IDs. Additionally, the client can encrypt and rotate the session tickets to prevent them from being reused or stolen by malicious actors.

5 What are the disadvantages of using TLS session tickets?

Using TLS session tickets can also have some drawbacks for your web application, such as increased memory and storage requirements on the client side, reduced compatibility and interoperability, and potential privacy and security risks. The client needs to store and manage the session tickets, some clients or servers may not support or implement the session ticket extension properly, and attackers may be able to decrypt or forge them.

6 How to choose between TLS session tickets and session IDs?

There is no definitive answer to whether you should use TLS session tickets or session IDs for your web application, as it depends on various factors, such as your performance goals, your security requirements, your load balancing strategy, your session affinity needs, and your client and server capabilities. You may also consider using other methods of TLS session resumption, such as pre-shared keys (PSKs) or early data (0-RTT), which are part of the latest TLS 1.3 standard. The best way to decide is to test and compare different options, and evaluate their trade-offs and benefits for your specific scenario.

7 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?