[alert] could not add new SSL session to the session cache while SSL handshaking

Lukas Tribus luky-37 at hotmail.com
Sun Mar 9 11:23:23 UTC 2014


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 		 	   		  


More information about the nginx mailing list