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@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@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> >

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


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

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