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

[Maxim Dounin]

Hello!

On Sun, Mar 09, 2014 at 12:23:23PM +0100, Lukas Tribus wrote:

> 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

Length of a serialized session may also vary depending on a key 
size negotiated, various TLS extensions negotiated and so on.  Try 
looking into d2i_SSL_SESSION() source.

I also suspect the comment you are referring to is largely 
outdated, and modern numbers are very different.

> > 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.

The ssl_buffer_size directive is completely unrelated to session 
caching.

> 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?

At worst, the cache won't be effective for as many new sessions as 
many "bad" sessions previously added to it (or rather half of that 
number, assuming removing two "bad" sessions frees enough space 
for one new session).  And this is basically identical to what can 
be done by just adding new sessions to the cache, thus forcing 
expiration of previously added sessions.

> Wouldn't it be better:
> - drop all expired sessions from cache instead of just one or two?

If for each session added two expired sessions are removed, this 
basically means that there will be no expired sessions - but work 
done on each particular request is limited.

> - 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)

I don't think your calculations are correct, but dropping couple 
of sessions instead of just one may be beneficial.  On the other 
hand, it has a downside of making it easier to expire previously 
stored sessions.

-- 
Maxim Dounin
http://nginx.org/