'SSL Session Resumption using Cached Session IDs'

Question

Is supporting 'SSL Session Resumption using Cached Session IDs' by SSL Servers secure ? Is Session Hijacking possible in any way if this feature used ?

Answer 1

Yes, it's secure in that most implementations do it properly and the method is not flawed. However it does make it more likely that you'll reach a point where re-negotiation will occur - and there are a number of vulnerabilities in that area. OTOH disabling ssl sessions for HTTP will have a dire effect on performance.

Answer 2

There is no known weakness with regards to session resumption, as it is implemented in SSL/TLS. It is actually something which was already done properly back in SSL 3.0, and did not change since.

One noteworthy point is related to a situation where you use certificate-based client authentication, and the client uses a smartcard which requires a PIN. When the first handshake was done, a digital signature was computed on the client side, and the PIN must have been entered. If the server accepts to resume that connection, then the PIN will not be entered again. As such, SSL session resumption is at odds with the server trying to get the user to enter his PIN again (to make sure, from the server point of view, that the human user is "still there"). Note that browsers and operating systems tend to cache PIN code ("to help users") so disabling session resumption is not sufficient to get this kind of guarantee anyway.

Without SSL session resumption, you will do more asymmetric cryptography on the server (so higher CPU consumption -- but this is rarely a real issue), and, more importantly, you will use more network bandwidth and have a higher connection latency (the "full handshake" entails a few more kilobytes of data and one extra roundtrip, compared to the "abbreviated handshake" that you get with SSL session resumption). Thus, it is really recommended to allow SSL session resumption, on a general basis.