-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rationale for ssl_session_timeout & ssl_session_cache shared settings? #198
Comments
This change sets ssl_session_timeout & ssl_session_cache to the values recommended by https://mozilla.github.io/server-side-tls/ssl-config-generator/ But I’m not sure what the rationale for those recommended values is, so I’ve also raised mozilla/server-side-tls#198 in hopes of getting an explanation.
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. |
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: Thanks! |
Currently, our ssl session timeout is for one day. This has led to a shortage of sessions, which occasionally leads to the following error: 2021/02/02 01:01:15 [alert] 492#492: *127421 could not allocate new session in SSL session shared cache "MozSSL" while SSL handshaking, client: 128.199.23.243, server: 0.0.0.0:443 Running out of sessions is not actually a big problem (see https://trac.nginx.org/nginx/ticket/621) but these errors regularly trigger alerts notification on our monitoring channel, which leads to notification fatigue. However, since: - we don't expect our individual sessions to actually last for a day - nginx sets a default of 5 minutes for this parameter (http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_timeout) We figured that it would not be a big problem to reduce the value of the ssl_session_timeout config. To be conservative, we will be setting it to one hour (as an upper bound on what a reasonable isomer session would be) which is still significantly more than nginx's default. Other references: - mozilla/server-side-tls#198 (comment)
Why such a high setting for
ssl_session_timeout
?I trust that there’s a solid rationale for both these specific values:
…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 thessl_session_timeout
value, an appropriately high value forssl_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 forssl_session_timeout
.And still, that said, as far as
ssl_session_cache
, why50m
exactly instead of, say,30m
or75m
? Is there a rule of thumb to calculate the rightssl_session_cache
value given assl_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: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-hour
ssl session timeout
value, @ivanr recommends settingssl_session_cache
to the really-low value of only1m
…)The text was updated successfully, but these errors were encountered: