SSL session resumption. SSL Labs test.

António P. P. Almeida appa at perusio.net
Mon Nov 22 19:34:29 MSK 2010


On 22 Nov 2010 15h26 WET, mdounin at mdounin.ru wrote:

Hello Maxim,

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

I've re-updated the Wiki and indicated that as the *preferred*
approach.

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

I've re-updated the Wiki and indicated that as the *preferred*
approach.

Going off in a tangent. Does the usage of GNU TLS instead of OpenSSL
as the underlying crypto library might mitigate this? There's now a
mod_gnutls for Apache. And it would be nice if Nginx had also
"competing" crypto modules. Just an idea.

Thanks,
--- appa




More information about the nginx mailing list