----- Original Message -----
> Hello!
>
> On Mon, Sep 16, 2013 at 12:51:38AM +0400, kyprizel wrote:
>
> > SSL session tickets are not good enough b/c they don't support
> > modern
> > cipher modes (like GCM) and they don't work with PFS.
>
> This was already replied by Piotr. Session tickets are just a way
> to store SSL session on the client, hence I see no problems with
> any ciphers. Forward secrecy might be a problem if you use
> long-term session tickets keys, but it's more about session
> tickets keys rotation.

agree

> > Is it generally possible to implement session lookup in non-blocking
> > way in
> > this case?
> > If yes - is there any good example of OpenSSL's non-blocking
> > callbacks?
>
> It should be possible, but it will likely require non-trivial
> changes in OpenSSL. And I don't know any good examples.


http://twistedmatrix.com/trac/browser/trunk/twisted/protocols/tls.py is in python and uses python wrapped OpenSSL calls however it is non-blocking.

> > P.S. As an alternative (and I don't like this idea) - we can
> > distribute
> > sessions to nginx cache via custom-written module, something like
> > it's done
> > in stud.
>
> This should be doable, and probably it's simpliest solution if you
> want to stick with server-side sessions store.

I was considering name space allocation in the tls ticket name amongst servers and an async distribution mechanism amongst servers (multicast?). Since there is a 120 bytes of bytes per server of session tickets allocating this on every web/mail server in a cluster probably isn't a high memory overhead and since the session key info is reused its not BW intensive either. It also solves some non-blocking aspects associated with key retrieval.

On client incompatibility (on ticket renewals), gnutls devs fixed it right away, openssl had already done a fix and nss I had troubles replicating the problem.



--
Daniel Black, Engineer @ Open Query (http://openquery.com)
Remote expertise & maintenance for MySQL/MariaDB server environments.

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