Rationale for ssl_session_timeout & ssl_session_cache shared settings?

[sideshowbarker]

Why such a high setting for ssl_session_timeout?

I trust that there’s a solid rationale for both these specific values:

ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;

…but I can’t find a rationale documented anywhere and would like to make sure I understand it.

From reading elsewhere, I understand setting a high value for ssl_session_timeout improves performance, and that when raising the ssl_session_timeout value, an appropriately high value for ssl_session_cache should also be set.

So from that, I can understand why ssl_session_cache is a relatively high value, but am just not sure why, to begin with, such an exceptionally high value is set for ssl_session_timeout.

And still, that said, as far as ssl_session_cache, why 50m exactly instead of, say, 30m or 75m? Is there a rule of thumb to calculate the right ssl_session_cache value given a ssl_session_timeout?

As far as ssl_session_timeout itself, most other guides I’ve read suggest setting it to one hour or at most three or four hours. However, in @ivanr’s book Bulletproof SSL and TLS I find this:

# Configure a shared memory cache of 1 MB.
ssl_session_cache shared:ssl_session_cache:1M;

# Expire individual sessions after 24 hours.
ssl_session_timeout 1440m; 

It's difficult to recommend one default configuration that will work for everyone… The default session timeout is only five minutes, which is too short. I used 24 hours instead. There is generally little reason to limit the session timeout, because you want to ensure that your cache runs at maximum capacity. If it runs out of space, the oldest session will be evicted to make room for a new one. That said, values over 24 hours are not recommended for security reasons.

So is that also the same rationale here?

---

(Incidentally as far as the recommended settings in Bulletproof SSL and TLS , I don’t understand why, given that 24-hourssl session timeout value, @ivanr recommends setting ssl_session_cache to the really-low value of only 1m…)

[ivanr]

There are no settings that are perfect for everyone. Session resumption either creates a large server-side cache that can be broken into or, with tickets, kills forward secrecy. So you have to balance performance (you don't want your users to use full handshakes on every connection) and security (you don't want to compromise it too much). Different projects dictate different settings.

My guess is that people giving advice just pick a number. The TLS RFC recommends that sessions are not kept alive for more than 24 hours, so that's one point of view. My thinking is that you generally want to try to reuse the same TLS session for the duration of one user session. The timeout and maximum size combined limit your exposure. Once you choose a set of values you then need to monitor your session resumption to determine if you're happy with the cache hit ratio. If not, tune your parameters and repeat the process.

One reason not to use a very large cache (just because you can) is that popular implementations don't actually delete any records from there; even the expired sessions are still in the cache and can be recovered. The only way to really delete is to overwrite them with a new session.

These days I'd probably reduce the maximum session duration to 4 hours, down from 24 hours currently in my book. But that's largely based on a gut feeling that 4 hours is enough for you to reap the performance benefits, and using a shorter lifetime is always better. But, as I said, the only correct approach is to understand your exposure, measure and tune.

When it comes to session resumption, I think it's more important to focus on understanding and limiting the lifetime of session ticket keys. Unless you're explicitly doing this already, chances are that you're reusing the same keys for as long as the web server stays up.

[april]

The size is what nginx recommends in their documentation, and the maximum time is due to the RFC. That said, I don't have strong feelings either way.

If you still feel this is important, we can always discuss on the new GitHub repo for the generator:
https://github.com/mozilla/ssl-config-generator

Thanks!