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 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 wealth and prosperity that doesn't include
crime, illness, therapy, hate, education, awareness, civil-liberty,
objectivity, corruption, art, culture, nature, or quality of life, air,
water, or food. Hence the expression; "a means to an end".
______________________________________________________________________
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]
