7

We already have SSL session resumption enabled using a session cache. Based on an in-house performance report, enabling Session Resumption using Session Tickets is recommended.

Is the performance increase gained from this worth the additional security risk? (From what I understand there is only a problem if the client is compromised. Could a compromise of one/several clients lead all encrypted traffic being compromised?)

Would there be failures/problems if not all clients supported this? (From what I can see the client will advertise it that it support Session Tickets and then server will react accordingly, clients who do not support this will not be affected)

rudolfv
  • 173
  • 1
  • 5

2 Answers2

14

If a client is compromised then that client is compromised. Session tickets don't change that one way or another...

Session tickets are a TLS extension by which the server pushes the session context into the client. From the point of view of the client, the ticket is opaque. To prevent ticket forgery or alteration by malicious clients, the server is supposed to employ some encryption and integrity check when it builds the ticket. If the server does its job properly (e.g. as recommended in the RFC), then session tickets do not introduce any extra weakness. A compromised/malicious client will not learn anything that allows it to decrypt the TLS sessions of other clients, or forge tickets.

The only situation where session tickets are not recommended is when servers want fine-grained control on the maximum duration of the session for each client, independently of other clients (e.g. if your Web site session management relies on the TLS session instead of some HTTP-level cookie or something similar). When the session context is saved server-side, it is easy for the server to simply forget that context. With session tickets, you cannot enforce forgetfulness on the client side. But we are not talking weaknesses here, only functionalities.

Since TLS session tickets are a TLS extension, they do not impact clients that do not know about them. A given TLS connection will use a ticket only if the client explicitly announces support for the extension in the ClientHello message. If a client does not support TLS session tickets (e.g. IE on Windows 7), then it won't talk about session tickets in its ClientHello, and neither will the server say anything about session tickets.

The consequence, though, is that even if you activate session tickets, this is an opportunistic optimization. The server must still be able to handle "normal" sessions for clients that do not support session tickets. You shall not disable non-ticket sessions until all clients have implemented the new support. Since the TLS implementation in Windows 7 does not know about session tickets, you will probably have to keep on supporting non-ticket sessions for some years still.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
0

Session Tickets in Combination with TLS 1.2 are the weakest link in modern TLS deployments. https://words.filippo.io/we-need-to-talk-about-session-tickets/

phiphi
  • 101