SSL Session Caching - Memcached

[Nipunn Koorapati]

Ah. I hadn't seen Daniel's response yet. Thanks for the reply.

I looked into session tickets, but they do not provide forward secrecy.
Unless keys are randomly generated and rotated with high frequency, there
will exist a single point of attack on the side. The cached session-id
mechanism provides this, which is why I'm looking into it.

Of course, I understand your point about synchronous blocking operations.
It looks like memcached provides asynchronous get/set methods, however it
doesn't look like there are hooks into OpenSSL to split up the
SSL_CTX_sess_set_*_cb methods. For the memcache_set call, we could switch
to being asynchronous fairly easily. For the memcache_get call, memcache
provides 2 separate methods. We could do some additional h4x and
setjmp/longjmp from the memcache call point to our event loop, but I assume
there's going to be some pushback to that idea.

In either case, we'd also want aggressive configurable timeouts for the
calls to memcached.

Is there some philosophical qualm with adding a dependency to memcache, or
is it just the concern of having a blocking call in the worker event loop.
I think we may be able to work around that.

Thanks
--Nipunn



On Wed, Apr 2, 2014 at 5:35 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Tue, Apr 01, 2014 at 06:06:10PM -0700, Nipunn Koorapati wrote:
>
> > I was able to graft the patch. It compiles and runs successfully. It
> > required a bit more work obviously as the code has changed since version
> > 0.8, but I think I covered it. Also had to make some modifications to the
> > mail-ssl module as it had dependencies. Is there some nginx tests /
> > testsuite module I should verify against / add tests to?
>
> There is a test suite as available at
> http://hg.nginx.org/nginx-tests.
>
> On the other hand, as already pointed out by Daniel, the patch in
> question isn't something to be seriously considered.  It's just a
> dirty hack.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140402/fa91141e/attachment.html>