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]
