Some sites, as seen in the report for www.mbank.com.pl [ssllabs.com] or report for aliorbank.pl [ssllabs.com] do not support "Session resumption", either because IDs are assigned but not accepted (first case) or because IDs are empty (second case).

It's not related to secure renegotiation, as visible in report for poczta.interia.pl [ssllabs.com] where the session resumption is unavailable while renegotiation is performed in secure manner.

Question: Why it's in red? Is it a security vulnerability?

2 Answers 2


Not supporting session resumption is not a security vulnerability; but it implies a new handshake per connection, which can increase latency (a full handshake implies more roundtrips than a resumed session) and CPU cost (mostly on the server, with the common RSA key exchange).

The first server is somewhat discourteous, in that it returns a non-empty session ID that it will refuse anyway; what the second server does (returning an empty ID) is what the SSL/TLS standard recommends. Yet returning a non-empty session ID for an unresumable session is not a true bug.

Presumably, ssllabs.com uses the red color here because it is relatively uncommon to deactivate session resumption -- and thus this may be a "configuration bug" worth reporting (although the red might veer a bit too much on the scary).


As Thomas already pointed out, disabling session resumption is not a vulnerability. Session resumption is actually a performance feature to reduce latency of subsequent requests to the same server made within a short span of time.

There is a reason some servers return a session ID then refuse to accept it (which this test is complaining about). I recall this behavior being a workaround for at least one browser that failed to properly handle a lack of a session ID [citation needed].

As for your connection, disabling session resumption can actually improve security. Session resumption can harm the effectiveness of forward secrecy by continuing to reuse sessions.

In some cases a badly configured server can completely negate all the benefits of forward secrecy by configuring their server to store resumption details for a long period of time. RFC4346 suggests a 24 hour upper limit on a sessions lifetime, however it is still suggested that browsers accept whatever lifetime the server uses.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .