Hi Maxim,
> You've changed SSL session timeout from 10 minutes to 24 hours, > and this basically means that sessions will use 144 times more > space in session cache. On the other hand, cache size wasn't > changed - so you've run out of space in the cache configured. If > there is no space in a cache nginx will try to drop one > non-expired session from the cache, but it may not be enough to > store a new session (as different sessions may occupy different > space), resulting in alerts you've quoted. I'm trying to understand this better, and read the comments in ngx_ssl_new_session(). Please tell if I got this right. Basically this can only happen if we delete a SSLv2 session from the cache and but need the space for a SSLv3/TLS session (SSLv2 session id needs 16 bytes and a SSLv3/TLS session id 32 bytes). So if SSLv2 hasn't been enabled via ssl_protocols directive, this problem will not happen, correct? Also this cannot happen on a 64-bit platform, as we use 128 bytes sized allocations for the session id + ASN1 representation even with SSLv2. So the two workarounds to avoid this problem in production would be: - disable SSLv2 (which is default anyway and shouldn't be enabled) - use a 64-bit platform > Note well that configuring ssl_buffer_size to 1400 isn't a good > idea unless you are doing so for your own performance testing. > See previous discussions for details. Sure, but in a production environment we also need to consider that we hit such limits, even if buffer_size and timeouts are tuned and state of the art. An attacker can flood the SSL session cache easily and if he is aware of such a limitation he could flood it with SSLv2 sessions, basically disabling the SSL session cache, right? Wouldn't it be better: - drop all expired sessions from cache instead of just one or two? - try dropping up to 4 non-expired session times before giving up (max allocation is 128, min allocation is 32, max / min = 4 sessions to drop in the worst case) Please let me know if I understood this correctly, thanks! Regards, Lukas _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
