SSL session resumption. SSL Labs test.

[Maxim Dounin]

Hello!

On Mon, Nov 22, 2010 at 03:39:06AM +0000, António P. P. Almeida wrote:

> On 22 Nov 2010 03h02 WET, mdounin at mdounin.ru wrote:
> 
> Hello Maxim,
> 
> Thank you for your reply.
> 
> 
> > Session establishmen/resumption happens before SNI handling.  
> > Therefore configuring session cache within SNI-only server{} won't 
> > work, you have to configure one in default server for the socket 
> > in question.
> 
> So the session resumption is done using a mapping that related IPs
> with session IDs. Completely oblivious to anything related with
> server_name.
> 
> > This is how it's done in OpenSSL, and it seems to be what actually 
> > required by RFC4366 (http://tools.ietf.org/html/rfc4366#section-3):
> >
> > -  If, on the other hand, the older session is resumed, then the
> > server MUST ignore the extensions and send a server hello
> > containing none of the extension types.  In this case, the
> > functionality of these extensions negotiated during the original
> > session initiation is applied to the resumed session.
> 
> I tried this:
> 
> listen [::]:443 ssl default_server; # ipv6
> 
> while leaving the '_' server_name for the HTTP default server. But
> gnutls-bin gives the same results. No session resumption support. It
> requires a regular default_server, i.e., 

I've played a bit with this, and it seems the only working 
configuration is having identical ssl_session_cache in all 
SNI server{}'s.

Anything else will not work due to the fact that OpenSSL uses 
initial context (i.e. default server's one) for session caching, 
but current context (i.e. server name matched server's) e.g. to 
decide whether advertise session id to client or not.

I.e. the following configuration will not cache sessions to 
"test.example.com":

    ssl_session_cache off;

    server {
        listen 443 ssl default;
        ssl_session_cache shared:SSL:10m;
        ...
    }

    server {
        listen 443;
        server_name test.example.com;
        ...
    }

Additionally, when shared cache is used, nginx will be confused by 
new session/remove session callbacks called with ssl connection 
with context which is not expected to have any session callbacks.  
E.g. this configuration will generate SIGSEGV on request to 
"test.example.com":

    server {
        listen 443 ssl default;
        ssl_session_cache shared:SSL:10m;
        ...
    }

    server {
        listen 443;
        server_name test.example.com;
        ssl_session_cache builtin;
        ...
    }

Simpliest (and recommended) workaround for both problems is to use 
ssl_session_cache defined at http{} level.  I.e.

    ssl_session_cache shared:SSL:10m;

    server {
        ...
    }

    ...

Maxim Dounin