On 22 Nov 2010 15h26 WET, mdounin@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


_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx