<div dir="ltr"><div>Ah. I hadn't seen Daniel's response yet. Thanks for the reply.</div><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>In either case, we'd also want aggressive configurable timeouts for the calls to memcached.</div><div><br></div><div>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.</div>

<div><span></span></div><div><br></div><div>Thanks<span id="dbph-30"></span></div>
<div>--Nipunn</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 2, 2014 at 5:35 AM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<div class=""><br>
On Tue, Apr 01, 2014 at 06:06:10PM -0700, Nipunn Koorapati wrote:<br>
<br>
> I was able to graft the patch. It compiles and runs successfully. It<br>
> required a bit more work obviously as the code has changed since version<br>
> 0.8, but I think I covered it. Also had to make some modifications to the<br>
> mail-ssl module as it had dependencies. Is there some nginx tests /<br>
> testsuite module I should verify against / add tests to?<br>
<br>
</div>There is a test suite as available at<br>
<a href="http://hg.nginx.org/nginx-tests" target="_blank">http://hg.nginx.org/nginx-tests</a>.<br>
<br>
On the other hand, as already pointed out by Daniel, the patch in<br>
question isn't something to be seriously considered.  It's just a<br>
dirty hack.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" target="_blank">http://nginx.org/</a><br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</font></span></blockquote></div><br></div>