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.
