RE: SSLSessionCacheTimeout
> From: Geoff Thorpe [mailto:[EMAIL PROTECTED]] > Sent: Saturday, September 08, 2001 11:30 AM > To: '[EMAIL PROTECTED]' > Subject: RE: SSLSessionCacheTimeout > Hi there, > On Fri, 7 Sep 2001, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: >> Geoff, >> Thanks for the detailed explaination - it does make a lot of sense.. >> As you've pointed out in case of SHMHT, if a server is lightly loaded, the >> session id will be cached for a time greater than the expiry time - but a >> session is NOT resumed based on this session-id. So, I guess it's still >> okay. I also fully understand your views of shmcb and dbm methods of >> caching. >I'm not sure you got the seriousness of the shmht situation. The problem is >not light loads, it's high loads. There is a global (although I assume I've done comparitive tests of the dbm, shmht, and shmcb caches on Apache servers using out cryptographic accelerator cards, under load, on Solaris, HP UX, AIX, and Linux, and the shmcb cache was by far the performance winner, and particularly so if the high load lasted for any significant time. Lynn Gazis Rainbow Technologies __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: SSLSessionCacheTimeout
Hi there, On Fri, 7 Sep 2001, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > Geoff, > Thanks for the detailed explaination - it does make a lot of sense.. > As you've pointed out in case of SHMHT, if a server is lightly loaded, the > session id will be cached for a time greater than the expiry time - but a > session is NOT resumed based on this session-id. So, I guess it's still > okay. I also fully understand your views of shmcb and dbm methods of > caching. I'm not sure you got the seriousness of the shmht situation. The problem is not light loads, it's high loads. There is a global (although I assume per-process) time_t value that is stamped each time *real* expiry logic is performed. All other "expire" attempts in future will silently return without any action until SSLSessionCacheTimeout seconds have passed since that time_t timestamp ... the first "expire" function call after that interval has passed will do real expiry processing and will reset the time_t value. So the problem is this - if you negotiate a new session *just* after a real expiry operation has taken place ... then in all likelihood, the next real expiry will take place just before your session is due to expire. So it won't be removed. However, it will "expire" just after the expire operation has taken place, and so will sit there until the next real expiry - despite the fact that is spends most of that interval "stale" (can't and won't be resumed). This poses a storage problem - its presence can still stop new sessions being cached even though it is old and wasting space. When you have a cache under high-load (ie. where the cache is kept full) then we'd expect mathematically for 67% of the cache to hold sessions that aren't too old, and 33% to hold sessions that are old and wasting space. This would be OK if inserts always succeeded by flushing out the oldest available session - but shmht's internal design makes that infeasible (the reason a time_t timestamp is used to prevent real expiry handling happening too often is that the expiry logic in shmht is necessarily a very expensive operation). It's why shmcb was written - real expiry logic is trivially fast so happens all the time (rather than "faking" it and only doing real work every "Timeout" seconds). That and the "insert always works" properties were the main motivations for it. > Anyway, your point is well taken. I guess it's a issue of security vs > performance - and I'm sure security takes a upper hand. Simplicity is probably the key word in all this. :-) Cheers, Geoff __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: SSLSessionCacheTimeout
On Fri, Sep 07, 2001 at 06:26:18PM -0700, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > Thanks for that feedback.. When I meant "reset the timeout", I certainly > did not mean to do it for ever.. There has to be a limit - either the number > of times the reset is done or the time limit - or both. The timeout that I > was thinking of is some thing like > (10 * SSLSessionCacheTimeOut > global_timeout < 1500) You can do this at an application specific basis. It does not hurt, as long as you make sure that sessions will expire after some reasonable amount of time. I cited from RFC 2246. ForPostfix/TLS I have decided for default timeout of 1 hour. Timeout values in the range of 15-30 seconds don't make any sense to me. If you load a page with a lot of subobjects, the session would even expire before the last items are loaded. > But if the mod_ssl gurus agree to have a bigger timeout, it's fine with me. > 'else, I can try including the logic in Apache 2.0. The downside of your approach is, that you have to add additional logic to your code, so that after each SSL_accept() with SSL_session_reused()=1 you have to adjust the timeout value of the session, which will be a pain in the a* to do when using external session caching. Please be aware, that a session that is in the backing store does not receive the timeout update. It is only updated in the internal session cache (for the process using the internal cache). Due to this problem I also don't see a simple idea how to solve this problem by an extension to OpenSSL (it would not be difficult to add a second timeout value and to update sessions that are reused automatically), but keeping this synchronized with the external session cache would complicate things significantly. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: SSLSessionCacheTimeout
Geoff, Thanks for the detailed explaination - it does make a lot of sense.. As you've pointed out in case of SHMHT, if a server is lightly loaded, the session id will be cached for a time greater than the expiry time - but a session is NOT resumed based on this session-id. So, I guess it's still okay. I also fully understand your views of shmcb and dbm methods of caching. Just to clarify my point : consider slow connections, and suppose the cache timeout is set to 30 seconds. It so happens many a times, the connection comes back to the server after a delay of around 20 - 25 seconds - under such circumstances, we're forcing those slow clients/connections to renegotiate for every connection. To further complicate the issue, all the clients have a client certificate. This renegotiations may cause a severe performance hit. I'm just trying to evaluate if it's fair to give a choice to the user - the SessionTimeout and/or the CacheTimeout. SessionTimeout is the global timeout (no connections/sessions are encouraged beyond this time), and CacheTimeout - is the timeout after which a session is liable to be removed from the cache (unless a request comes in at the nth moment) Anyway, your point is well taken. I guess it's a issue of security vs performance - and I'm sure security takes a upper hand. -Madhu -Original Message- From: Geoff Thorpe [mailto:[EMAIL PROTECTED]] Sent: Friday, September 07, 2001 1:04 PM To: '[EMAIL PROTECTED]' Subject: Re: SSLSessionCacheTimeout Hi there, On Fri, 7 Sep 2001, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > If my understanding is correct, the current logic for > SSLSessionCacheTimeout (in mod_ssl) is to mark the time when the first > request was received, and then, irrespective of how long the connection has > been active/inactive, remove the session identifier from the cache after the > timeout has expired.. > i.e., suppose the timeout is set to 15 seconds, the first request is > received at 10:15:30 am, the next request from the same client arrives at > 10:15:44, and a third request arrives at 10:15:55 - SSL will force a > re-negotiation for the third case.. Yes > I was wondering if the above logic makes sense, or is it better to reset the > timeout as and when a request is processed - i.e., reset the timeout to be > 10:15:49 after the 2nd request is processed, reset it to be 10:16:20 after > the 3rd request - goes on till a request is not received from the same > client OR the timeout expires.. > > Any inputs / feedback is welcome.. It is important to understand the significance of session caching. It is a performance enhancement, and if anything at all, poses a potential threat of reducing *effective* security. The security issue is not really a cryptographic one, but more a toyware one. Ie. If your server accepts session resumption over huge gaps in time, and toyware client software doesn't do a good job of managing, protecting, and invalidating session information at the client end, the the session information that lurks around at the client end plus the ability to use it to act in a capacity you should not, become a possible target for attack. To avoid landing myself in a libel suit, I will resist specifying any toyware client applications by name, but the fact they exist and are enormously widespread is commonly acknowledged. The timeout on a session is also a concept subject to much misunderstanding. The timeout should be a statement that "even if the client wants to resume it after 'x' seconds, and the server still remembers it from way back then, after 'x' seconds we will *not* honour a resume request but will force the negotiation of a new session instead". Ie. it's an upper-limit you wish to set on session persistence. Unfortunately, session timeouts are usually chosen for different reasons altogether. The "shmht" cache for example (aka "shm") will never remove an existing session until it has passed its expiry time (in fact the average case under load keeps *old* sessions in the cache until they're 50% past their expiry time). As a consequence, if the cache fills up, adding brand new sessions may fail until such time as cache entries start to pass their "used-by" date. This can have pretty bad performance consequences (if your cache is full it's probably because your server is busy - so never caching new sessions will probably cause your server to get even busier than it was). So people tend to choose session timeouts on the following criteria; (i) long enough that they can reap performance benefits from rapid-fire requests (eg. downloading hundreds of web-page graphics using the same SSL/TLS session that grabbed the original HTML). (ii) short enough that the cache never fills-up with unexpired sessions, thus blockin
RE: SSLSessionCacheTimeout
Lutz, Thanks for that feedback.. When I meant "reset the timeout", I certainly did not mean to do it for ever.. There has to be a limit - either the number of times the reset is done or the time limit - or both. The timeout that I was thinking of is some thing like (10 * SSLSessionCacheTimeOut > global_timeout < 1500) I'm not comfortable with the idea of having a bigger timeout and correspondingly more session identifiers in the session cache - thus deferring the renegotiation (this way, we'd be solving the symptom, rather than the cause).. But if the mod_ssl gurus agree to have a bigger timeout, it's fine with me. 'else, I can try including the logic in Apache 2.0. Looking forward for your feedback.. Thanks -Madhu -Original Message- From: Lutz Jaenicke [mailto:[EMAIL PROTECTED]] Sent: Friday, September 07, 2001 11:45 AM To: '[EMAIL PROTECTED]' Subject: Re: SSLSessionCacheTimeout On Fri, Sep 07, 2001 at 09:52:42AM -0700, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > If my understanding is correct, the current logic for > SSLSessionCacheTimeout (in mod_ssl) is to mark the time when the first > request was received, and then, irrespective of how long the connection has > been active/inactive, remove the session identifier from the cache after the > timeout has expired.. > i.e., suppose the timeout is set to 15 seconds, the first request is > received at 10:15:30 am, the next request from the same client arrives at > 10:15:44, and a third request arrives at 10:15:55 - SSL will force a > re-negotiation for the third case.. > > I was wondering if the above logic makes sense, or is it better to reset the > timeout as and when a request is processed - i.e., reset the timeout to be > 10:15:49 after the 2nd request is processed, reset it to be 10:16:20 after > the 3rd request - goes on till a request is not received from the same > client OR the timeout expires.. Using this logic a second timeout value would be required, after which a session would definitely be removed. RFC2246 (TLS) recommends to not use a session longer than 24 hours. I've also read recommondations that sessions with export ciphers (e.g. 40bit) should not be used longer than 1 hour. Using your logic, it would be possible to keep a session infinitely long. If you have a problem with sessions expiring to soon, increase the timeout value (at the cost of needing more entries in the session database). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: SSLSessionCacheTimeout
> The timeout on a session is also a concept subject to much > misunderstanding. I've always though TTL, TimeToLive, was a better name. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: SSLSessionCacheTimeout
Hi there, On Fri, 7 Sep 2001, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > If my understanding is correct, the current logic for > SSLSessionCacheTimeout (in mod_ssl) is to mark the time when the first > request was received, and then, irrespective of how long the connection has > been active/inactive, remove the session identifier from the cache after the > timeout has expired.. > i.e., suppose the timeout is set to 15 seconds, the first request is > received at 10:15:30 am, the next request from the same client arrives at > 10:15:44, and a third request arrives at 10:15:55 - SSL will force a > re-negotiation for the third case.. Yes > I was wondering if the above logic makes sense, or is it better to reset the > timeout as and when a request is processed - i.e., reset the timeout to be > 10:15:49 after the 2nd request is processed, reset it to be 10:16:20 after > the 3rd request - goes on till a request is not received from the same > client OR the timeout expires.. > > Any inputs / feedback is welcome.. It is important to understand the significance of session caching. It is a performance enhancement, and if anything at all, poses a potential threat of reducing *effective* security. The security issue is not really a cryptographic one, but more a toyware one. Ie. If your server accepts session resumption over huge gaps in time, and toyware client software doesn't do a good job of managing, protecting, and invalidating session information at the client end, the the session information that lurks around at the client end plus the ability to use it to act in a capacity you should not, become a possible target for attack. To avoid landing myself in a libel suit, I will resist specifying any toyware client applications by name, but the fact they exist and are enormously widespread is commonly acknowledged. The timeout on a session is also a concept subject to much misunderstanding. The timeout should be a statement that "even if the client wants to resume it after 'x' seconds, and the server still remembers it from way back then, after 'x' seconds we will *not* honour a resume request but will force the negotiation of a new session instead". Ie. it's an upper-limit you wish to set on session persistence. Unfortunately, session timeouts are usually chosen for different reasons altogether. The "shmht" cache for example (aka "shm") will never remove an existing session until it has passed its expiry time (in fact the average case under load keeps *old* sessions in the cache until they're 50% past their expiry time). As a consequence, if the cache fills up, adding brand new sessions may fail until such time as cache entries start to pass their "used-by" date. This can have pretty bad performance consequences (if your cache is full it's probably because your server is busy - so never caching new sessions will probably cause your server to get even busier than it was). So people tend to choose session timeouts on the following criteria; (i) long enough that they can reap performance benefits from rapid-fire requests (eg. downloading hundreds of web-page graphics using the same SSL/TLS session that grabbed the original HTML). (ii) short enough that the cache never fills-up with unexpired sessions, thus blocking the insertion of new sessions. (iii) if they use client certificates, they may have to cache things in certain ways (and deliberately invalidate sessions in certain circumstances) to make for a "meaningful client experience". Ie. being prompted for client key passphrases at the "right" time and *not* being repeatedly pestered for them at the "wrong" times. The "dbm" cache implementation (IIRC), and the alternative "shmcb" cache do not block the insertion of new sessions *ever*. If a new session is negotiated and the server wants to cache the session, it will be added to the cache. The logic when confronted with a full-cache is inverted such that the cache item(s) who are due to expire *next* are flushed out prematurely. IIRC, "dbm" will simply let the cache grow as big as it needs at any time to accomodate all new sessions whilst never prematurely expiring existing ones. For shmcb, this is not possible as the shared-memory segment is of fixed size - so the result is that under high-loads, sessions that are marked to become non-resumable after 'x' seconds may in fact become non-resumable before that (ie. they're removed when the cache is full and they've become the oldest "living" session). As/when the loads drop, sessions will remain resumable for progressively longer intervals. If the load gets low enough, eventually sessions will only be flushed out of the cache when their 'x' seconds are up (ie. SSLSessionCacheTimeout). I don't know if that answers your question the way you wanted, but I hope it helps anyway. Cheers, Geoff -- Geoff Thorpe http://www.geoffthorpe.net mailto:geoff@geoffthorpe(dot)net Capitalism - a means to quantify
Re: SSLSessionCacheTimeout
Lutz, Thanks for that feedback.. When I meant "reset the timeout", I certainly did not mean to do it for ever.. There has to be a limit - either the number of times the reset is done or the time limit - or both. The timeout that I was thinking of is some thing like (10 * SSLSessionCacheTimeOut > global_timeout < 1500) I'm not comfortable with the idea of having a bigger timeout and correspondingly more session identifiers in the session cache - thus deferring the renegotiation (this way, we'd be solving the symptom, rather than the cause).. But if the mod_ssl gurus agree to have a bigger timeout, it's fine with me. 'else, I can try including the logic in Apache 2.0. Looking forward for your feedback.. Thanks -Madhu -Original Message- From: Lutz Jaenicke [mailto:[EMAIL PROTECTED]] Sent: Friday, September 07, 2001 11:45 AM To: '[EMAIL PROTECTED]' Subject: Re: SSLSessionCacheTimeout On Fri, Sep 07, 2001 at 09:52:42AM -0700, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > If my understanding is correct, the current logic for > SSLSessionCacheTimeout (in mod_ssl) is to mark the time when the first > request was received, and then, irrespective of how long the connection has > been active/inactive, remove the session identifier from the cache after the > timeout has expired.. > i.e., suppose the timeout is set to 15 seconds, the first request is > received at 10:15:30 am, the next request from the same client arrives at > 10:15:44, and a third request arrives at 10:15:55 - SSL will force a > re-negotiation for the third case.. > > I was wondering if the above logic makes sense, or is it better to reset the > timeout as and when a request is processed - i.e., reset the timeout to be > 10:15:49 after the 2nd request is processed, reset it to be 10:16:20 after > the 3rd request - goes on till a request is not received from the same > client OR the timeout expires.. Using this logic a second timeout value would be required, after which a session would definitely be removed. RFC2246 (TLS) recommends to not use a session longer than 24 hours. I've also read recommondations that sessions with export ciphers (e.g. 40bit) should not be used longer than 1 hour. Using your logic, it would be possible to keep a session infinitely long. If you have a problem with sessions expiring to soon, increase the timeout value (at the cost of needing more entries in the session database). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: SSLSessionCacheTimeout
On Fri, Sep 07, 2001 at 09:52:42AM -0700, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > If my understanding is correct, the current logic for > SSLSessionCacheTimeout (in mod_ssl) is to mark the time when the first > request was received, and then, irrespective of how long the connection has > been active/inactive, remove the session identifier from the cache after the > timeout has expired.. > i.e., suppose the timeout is set to 15 seconds, the first request is > received at 10:15:30 am, the next request from the same client arrives at > 10:15:44, and a third request arrives at 10:15:55 - SSL will force a > re-negotiation for the third case.. > > I was wondering if the above logic makes sense, or is it better to reset the > timeout as and when a request is processed - i.e., reset the timeout to be > 10:15:49 after the 2nd request is processed, reset it to be 10:16:20 after > the 3rd request - goes on till a request is not received from the same > client OR the timeout expires.. Using this logic a second timeout value would be required, after which a session would definitely be removed. RFC2246 (TLS) recommends to not use a session longer than 24 hours. I've also read recommondations that sessions with export ciphers (e.g. 40bit) should not be used longer than 1 hour. Using your logic, it would be possible to keep a session infinitely long. If you have a problem with sessions expiring to soon, increase the timeout value (at the cost of needing more entries in the session database). Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
