Hi, * Nadav Har'El ([EMAIL PROTECTED]) wrote: > Hi, > > I noticed that SSL_CTX_free() takes all the sessions in the given CTX's > internal session cache, and also removes them from the external session cache > (i.e., calls the delete-session callback). > > Why was this done? I can't think of a security or a logical explanation to > this, because these sessions in the external cache are still valid, and other > contexts or processes might still want to reuse them!
Yeah this is dumb, but I think probably you are overreading the "design" of the relationship between the SSL_CTX-internal cache and external caching callbacks. For the good oil on this, you'll probably have to get in contact with Eric Young and convince him to discuss it with you. Short of that, my impression has been that it's no more than a horrible hack that was jammed in to solve a particular need at the time, and it has since installed itself in ssl/ and would now be difficult to substantially re-engineer without pissing off lots of people. One of the problems is the relationship between the internal cache operations and the cache callbacks. Ie. is the external cache supposed to replace the internal cache, or to allow it to bridge multiple SSL_CTX contexts (or copies of the same one inside forked child processes) using an external "parent" cache? Things aren't terribly natural in either case; eg. the SSL_SESS_CACHE_NO_INTERNAL_LOOKUP flag is pretty much obligatory if you want sane behaviour in the second case but is not the default for historical reasons. The alternative to that flag would be to add a new external callback similar to "get_session" that merely checks the continued existence of a session in the external cache, something like "has_session". This way, the internal cache could resume sessions it has locally cached by first checking that the external cache has not (through some other SSL_CTX's activity) explicitly invalidated or destroyed the corresponding session. BTW, this is the approach used in the www.distcache.org model. What you're noticing with the expiry of all sessions upon SSL_CTX_free() is perhaps evidence that the original intention of the external callbacks was to replace the internal cache rather than provide an umbrella for multiple internal caches. And then again, the fact the internal cache is maintained in parallel with the external one (rather than being ignored) suggests that perhaps someone was trying to have their cake and eat it too. Initially, it probably looked like that default behaviour killed two birds with one stone, but I think now the picture is a little less satisfying. I'm not sure about the real reasons to be honest though. > Looking at the SSL_CTX_free() code (ssl/ssl_lib.c), I see that > SSL_CTX_flush_sessions(a,0) is called - and from the manual page of > that function I understand that what this means is to mark sessions older > than time 0 (i.e., all sessions) as *expired*, and all these sessions > are also deleted from the external session cache. I don't understand why > this kind of behavior should be part of SSL_CTX_free(). I feel your pain. > By the way, it's relatively easy for me to overcome this behavior by > cancelling the delete-session callback before calling SSL_CTX_free() - but > I was wondering why I have to do that... IMHO, you're probably better off in the mean time disabling the internal caching altogether and implement a coherent model entirely from the external callbacks - this way the SSL_CTX_free() behaviour won't matter because the internal cache is empty so it won't be deleting anything in the external cache. Again, a shameless plug in the direction of www.distcache.org and the apache-1.3/mod_ssl and apache-2 patches show an illustration of this approach. For my own activities with caching, I felt quite early on that to bother implementing an external cache pretty much obligated me to forget about the internal caching. The ideal thing for openssl would be to wait until we have a good opportunity to well and truly ignore backwards compatibility and then just uproot the entire caching interface and replace it with something cleaner. This is not meant to be me bitching about Eric's SSLeay work - it's obvious we benefit from a certain retrospective 20/20 vision that Eric never had at the time. However, we're not yet at a point where we can go breaking large blocks of application code in non-trivial ways so we're sort of obligated to make gentle modifications, add extra flags, and "make do". However, when the revolution comes ... I don't know if that helps with your problem though? Are you able to do away with the internal cache, or are you committed to having sane interaction between internal and external caching? Note also that this is all IMHO, there may be others who consider the internal/external caching semantics to be fine as they are. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.openssl.org/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
