Could not allocate new session in SSL session shared cache “le_nginx_SSL” while SSL handshaking

I have a centos 8 server with nginx and certbot installed. When I check:

cat /var/log/nginx/error.log

I get this error a lot:

[alert] 2245236#0: *42902735 could not allocate new session in SSL session shared cache "le_nginx_SSL" while SSL handshaking, client: ip, server: ip

Would you know how to fix this issue?

Thank you.

1 Like

Does your site get a lot of traffic?

As https://trac.nginx.org/nginx/ticket/621 explain, this message is harmless. It won't cause errors for visitors. Instead, affected returning visitors would take a small efficiency penalty from not having SSL session resumption.

You could modify /etc/letsencrypt/options-ssl-nginx.conf and alter the following lines (bigger cache, or lower timeout, or both):

ssl_session_cache shared:le_nginx_SSL:10m;
ssl_session_timeout 1440m;

and then reload nginx. But keep in mind if you change this file, then Certbot won't apply automatic updates to it anymore. You'll have to keep it up to date manually.

Tuning these is tricky; there don't seem to be any concrete answers for "what values should I use when I get x SSL clients per day?". There seem to be some performance and security implications either way. To further complicate things, TLS 1.2 and TLS 1.3 differ with this specific configuration (session ID resumption only for the former, stateful tickets for the latter).

Some background reading:

tl;dr; Maybe try increase ssl_session_cache by 2x or 3x and see if the problem goes away?

@schoen you always have a pretty impressive grasp on big picture cryptography, what do you think about tuning in this case?

3 Likes

Aren't the security issues just that session resumption makes it easier for a network adversary to identify users (in TLS 1.2), easier for the web server operator to recognize users even without cookies or device fingerprinting (in both TLS 1.2 and 1.3) and effectively a less aggressive session key expiry for forward secrecy properties (maybe in both or maybe just in TLS 1.2)?

If so, I'd say most sites and most users haven't worked out a threat model that's explicit enough to clearly justify worrying much about this, unfortunately.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.