SSL Session Caching - Memcached

[Maxim Dounin]

Hello!

On Wed, Apr 02, 2014 at 02:37:28PM -0700, Nipunn Koorapati wrote:

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

As long as you cache sessions, forward secrecy isn't provided for 
still cached sessions either.  Moreover, storing sessions in 
memcached means that they can be easily accessed from a network 
where the memcached server is.  While this is solvable, it's 
hardly seriously better than shared session ticket keys with 
proper rotation.

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

Sure, OpenSSL as of now doesn't provide non-blocking session 
retrieval callbacks.  So the only sensible approach for 
distributed session cache is to keep all sessions on all nodes.

When this was discussed last time on this mailing list, the result 
was ssl_session_ticket_key implementation.

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

You are free to do whatever you want.  I just pointed out why this 
is not going to be included into nginx.

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

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


-- 
Maxim Dounin
http://nginx.org/