SSL session resumption. SSL Labs test.

[Maxim Dounin]

Hello!

On Mon, Nov 22, 2010 at 01:24:01AM +0000, António P. P. Almeida wrote:

> On 21 Nov 2010 22h55 WET, me at luitvd.net wrote:
> 
> > On Sun, Nov 21, 2010 at 11:43 PM, António P. P. Almeida
> > <appa at perusio.net> wrote:
> >> ...
> >> Isn't this enough? Can someone more knowledgeable than I in SSL/TLS
> >> stuff and Nginx shed some light on this issue? Should I ignore this
> >> result?
> >
> > The case might be that Qualys SSL Labs checks all this against the
> > IP address it resolves from the domain you give them. Apply those
> > SSL settings to the default server to make this all work there.
> 
> Ok. I think I get it. The test doesn't use SNI. Hence it checks
> against the default_server for the session resumption test. Since in
> this case this is just a regular HTTP server block with '_' as server
> name it doesn't associate the server where the certficate is installed
> with the session resumption test.
> 
> Is that it?

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.

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.

One can't resume session stored somewhere in server name related 
context while following "MUST ignore" rule.

Maxim Dounin