SSL_CTX_free messes with external session cache
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! 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(). 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... -- Nadav Har'El| Wednesday, Mar 26 2003, 23 Adar II 5763 [EMAIL PROTECTED] |- Phone: +972-53-245868, ICQ 13349191 |The human mind is like a parachute - it http://nadav.harel.org.il |functions better when it is open. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_CTX_free messes with external session cache
On Wed, Mar 26, 2003 at 08:25:10PM +0200, Nadav Har'El wrote: 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). [Analysis deleted.] Obviously this behaviour is worth discussing. Could it make sense? I have bounced your message into the Request Tracker to open a ticket. Hmm. I extensively use external session caching. But I never call SSL_CTX_free(), as my application will terminate in this moment anyway, so this oddity went by unnoted... Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_CTX_free messes with external session cache
On Wed, Mar 26, 2003, Lutz Jaenicke wrote about Re: SSL_CTX_free messes with external session cache: Hmm. I extensively use external session caching. But I never call SSL_CTX_free(), as my application will terminate in this moment anyway, so this oddity went by unnoted... This is the bane of C++: it's too easy to write a destructor, so I had one, and it called SSL_CTX_free(). And this destructor got called when a process exited (sort of like atexit(3), but a heck lot harder to debug). :) By the way, this problem is so easy to circumvent that even if you decide not to change the current behaviour, maybe the manual should be changed to say that one can use: SSL_CTX_sess_set_remove_cb(ctx, NULL); SSL_CTX_free(ctx); To free a ctx without having the remove callback called. -- Nadav Har'El| Wednesday, Mar 26 2003, 23 Adar II 5763 [EMAIL PROTECTED] |- Phone: +972-53-245868, ICQ 13349191 |Linux: Because rebooting is for adding http://nadav.harel.org.il |new hardware. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_CTX_free messes with external session cache
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/ __
Re: SSL_CTX_free messes with external session cache
On Wed, Mar 26, 2003, Geoff Thorpe wrote about Re: SSL_CTX_free messes with external session cache: 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 This is very true. In fact, I designed the application in question from the start to use only the external cache (if you remember, I was the one who asked to add the NO_INTERNAL flag - NO_INTERNAL_LOOKUP will still leave me with a big internal session cache). But for several silly and embarrassing reasons, I need to have both an internal and external session cache for now. :( The extra SSL_CTX_sess_set_remove_cb(ctx, NULL); before SSL_CTX_free(ctx) fixes the problem I reported, so it's not a real problem for me, it simply surprised me. 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 I understand that backward compatibility is important, if people rely on the current behaviour. In this case, I suggest that the manual pages (in this case, of SSL_CTX_free()) be updated to explain what actually happens, and perhaps how to get the other behaviour. Nobody can complain about this if it is explained in the manual :) -- Nadav Har'El| Wednesday, Mar 26 2003, 23 Adar II 5763 [EMAIL PROTECTED] |- Phone: +972-53-245868, ICQ 13349191 |The human mind is like a parachute - it http://nadav.harel.org.il |functions better when it is open. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_CTX_free messes with external session cache
* Nadav Har'El ([EMAIL PROTECTED]) wrote: 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 I understand that backward compatibility is important, if people rely on the current behaviour. In this case, I suggest that the manual pages (in this case, of SSL_CTX_free()) be updated to explain what actually happens, and perhaps how to get the other behaviour. Nobody can complain about this if it is explained in the manual :) As someone who now has an excellent working familiarity with the API behaviour, I am sure any patches (diff -u format) you were to contribute in this direction would be most warmly welcomed :-) 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]
