Hi there,
I'm not cross-posting this to modssl-users as the problem and solution
are mostly openssl-specific. Perhaps we can post a summary to
modssl-users once this is over with.
On Monday 21 Oct 2002 8:40 am, Nadav Har'El wrote:
> I ran the test again with the correct library, and OpenSSL 0.9.6g
> indeed does not cache new sessions in the internal cache (when
> NO_INTERNAL_LOOKUP), like I already noticed in the source code.
>
> But it does cache resumed sessions in the internal cache, again like I
> noticed in the source code (ssl_get_prev_session()) - so I think this
> is the bug.
Thanks for the detailed report - Lutz has already created an RT ticket
for this. I replied to the RT mail from him privately before noticing
these followups (from you both) on modssl-users and openssl-dev, so I'll
repeat here a suggestion I proposed in my mail to him, though I'll try
to elaborate a bit. I think perhaps the correct solution would be to
have things as follows;
- SSL_SESS_CACHE_NO_INTERNAL_LOOKUP
Lookups are not performed using the internal/local cache but solely
through (any) external cache-lookup callback. Make sure that cache
stores are nonetheless cached internally as well as through any
external callback - as it was before and perhaps is still the case in
some inconsistent buggy fashion, as you have suggested might be the
case. :-)
- SSL_SESS_CACHE_NO_INTERNAL_STORE (new flag)
Cache stores are not performed against the internal/local cache but
solely through (any) external cache-store callback. Lookups are
nonetheless performed internally before using any external callback.
- SSL_SESS_CACHE_NO_INTERNAL (new flag)
This is
(SSL_SESS_CACHE_NO_INTERNAL_LOOKUP|SSL_SESS_CACHE_NO_INTERNAL_STORE)
Combination of the both the above, and the appropriate replacement for
use in mod_ssl, Apache2, and other circumstances where fork() can
introduce security problems with cache state.
The reason I don't suggest changing the behaviour
SSL_SESS_CACHE_NO_INTERNAL_LOOKUP to not store sessions is two-fold;
(i) behavioural change of a flag that applications may be relying on
and will introduce an unforeseen bug.
(ii) it may actually be advantageous to have fine-grained control as
I've suggested with the 3 flags (well, the third being an
abbreviation for the OR of the first two).
W.r.t. (ii) I can invisage NO_INTERNAL_LOOKUP being used on its own with
the current behaviour - we may want a cache of sessions for manual
inspection by the application without the application having to
implement its own cache. With this flag, the application can be sure
that the SSL/TLS code won't automatically resume them without going via
its external callback - ie. the application itself will control those
sessions it is prepared to accept or not.
NO_INTERNAL_STORE may be similarly useful because the application can
know the SSL/TLS implementation will automatically resume any resumable
session in its cache, but the contents of that cache are only those
sessions that the application has manually inserted into the cache of
its own will - the SSL/TLS implementation won't automatically populate
the cache.
Obviously the combination will be useful too and in fact is what is
desired in Apache2/mod_ssl.
Any thoughts? I'm thinking out loud here - but will continue to think a
little more carefully (and quietly) about it.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
