On Sun, Oct 20, 2002, Geoff Thorpe wrote about "Re: Memory leak in session caching?": > Actually security is paramount, otherwise mod_ssl has no purpose at > all. Apache can actually cope with memory leaks pretty well so that it's > stability is not dependant on the perfect functioning of all its > modules. You just kill off child processes after they've served some > maximum number of requests (just set the "MaxRequestsPerChild" or
You're absolutely right. The limit I had set (1000) was too high for my case, but setting a lower limit would have worked (at some small cost of performance because of all that extra forking/killing). > > Too bad we can't tell OpenSSL also not to *put* stuff in that cache, > > Are you sure that it is storing sessions in an internal cache when that > flag is set? Well, the SSL_CTX_set_session_cache_mode(3) manual says about SSL_SESS_CACHE_NO_INTERNAL_LOOKUP that: "By setting this flag sessions are cached in the internal storage but they are not looked up automatically. ..." Which is why I assumed that it still caches sessions, even if it doesn't look them up. To make sure that the internal cache is indeed being filled up, I tried a simple experiment: In the NewSessionCacheEntry callback I added code that printed the current size of the internal cache. I printed: lh_num_items(ssl->ctx->sessions) and a second method (counting the linked list instead of the hash table) int n1 = 0; SSL_SESSION *s; for (s=ssl->ctx->session_cache_head; s; s=s->next) n1++; and to check that I didn't forget setting SSL_SESS_CACHE_NO_INTERNAL_LOOKUP I also printed ssl->ctx->session_cache_mode&SSL_SESS_CACHE_NO_INTERNAL_LOOKUP I than ran several requests (using curl, so sessions were never resumed), and sure enough, after 7 requests (to only one server process) I saw a message like items in ssl->ctx->sessions: 7 second algorithm: 8 ssl->ctx->session_cache_mode&NO_INTERNAL_LOOKUP: 100 (I don't know where that 8th session came from...). I did check, by the way, that SSL_SESS_CACHE_NO_INTERNAL_LOOKUP prevented the internal lookup. At least that :) (so this is indeed a solution to the security problem you raised) > > Frankly, I don't understand why that OpenSSL option exists at all. Why > > would anyone want to populate a cache that (s)he will never use? > > As I say, are you sure that sessions are being stored in the SSL_CTX > cache when the SSL_SESS_CACHE_NO_INTERNAL_LOOKUP flag is set? If I find > time, I'll try and dig back through the openssl list mail and take a > closer look at your post - but I guarantee nothing right now. If you I did that digging earlier today. Here is what I found. Note that I'm a very small OpenSSL expert (read: not at all), so take my analysis with a pound (not just a grain :)) of salt. In short, I found that SSL_SESS_CACHE_NO_INTERNAL_LOOKUP doesn't always prevent the internal session cached from being filled. In long, The relevant functions in OpenSSL are: (I looked at openssl-engine-0.9.6g) SSL_CTX_add_session (ssl/ssl_sess.c) ssl_update_cache() (ssl/ssl_lib.c) ssl_get_prev_session in (ssl/ssl_sess.c) SSL_CTX_add_session() (ssl_sess.c) is the function that actually adds a session to the internal cache. It always does it's job - it doesn't check session_cache_mode flags before doing it. So the question is whether this function is called when the flag SSL_SESS_CACHE_NO_INTERNAL_LOOKUP is set. SSL_CTX_add_session() is only called in two places in OpenSSL: in ssl_update_cache() (ssl_lib.c) and in ssl_get_prev_session() (ssl_sess.c). So now we need to check if those functions check the SSL_SESS_CACHE_NO_INTERNAL_LOOKUP flag or not. ssl_update_cache() (called when OpenSSL creates a new, not resumed, session) indeed *appears* not to call SSL_CTX_add_session() when SSL_SESS_CACHE_NO_INTERNAL_LOOKUP is on. This fits your guess, contradicts what the manual page says, and also seems to contradict with the experiment I outlined above - I can't explain it... The second function, ssl_get_prev_session() (called to fetch a session with an existing id), however, calls SSL_CTX_add_session WITHOUT first checking the NO_INTERNAL_LOOKUP flag! So when an answer is fetched from the external cache, it is also cached in the internal cache regardless of the NO_INTERNAL_LOOKUP flag. So to sum it up, I belive NO_INTERNAL_LOOKUP does not consistently prevent sessions from being entered into the cache; According to my experiment (which is not backed by firm understanding the source code, unfortunately) even in cases (new sessions) when sessions should apparently not be cached in the internal cache, they do end up being cached. I'm baffled, I have to admit. It will probably take a bigger OpenSSL expert than me to fully understand this. > have evidence that bad (or stupid) things are happening, please take the > analysis as far as you can and point us to a concise summary of the > problem - and if you're feeling very kind, a "diff -u" patch to fix the > problem wouldn't go amiss either. If you already did any/all of that, my > apologies - I'll see what I can do. I will continue researching this a bit, and will post here patches if I finally find a working one. The next thing I'm thinking of trying is to make the SSL_CTX_add_session() function itself (the function that physically puts the session in the internal cache) check the NO_INTERNAL_LOOKUP flag, not doing anything if that flag is on. Of course, that would contradict with the manual - perhaps a new flag is needed... But that is getting deep OpenSSL territory - I'll probably need to suggest such a patch to the OpenSSL people. Thanks, Nadav. -- Nadav Har'El | Monday, Oct 21 2002, 15 Heshvan 5763 [EMAIL PROTECTED] |----------------------------------------- Phone: +972-53-245868, ICQ 13349191 |Lottery: A tax on people who are bad at http://nadav.harel.org.il |math. ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]