On Mon, Nov 06, 2000 at 02:34:36PM -0500, Wohlgemuth, Michael J. wrote:
...
(There have been answers and hints for the other questions.)
> 4. The obvious workaround here is to increase the SSLSessionCacheTimeout.
> Is their any recommended maximum value for this?
Please check out the TLS standard RFC2246. There a maximum lifetime of
24 hours is recommended (based on security considerations) (F.1.4):
Sessions cannot be resumed unless both the client and server agree.
If either party suspects that the session may have been compromised,
or that certificates may have expired or been revoked, it should
force a full handshake. An upper limit of 24 hours is suggested for
session ID lifetimes, since an attacker who obtains a master_secret
may be able to impersonate the compromised party until the
corresponding session ID is retired. Applications that may be run in
relatively insecure environments should not write session IDs to
stable storage.
I have never tried whether e.g. Netscape actually enforces some timeout.
If I have long lasting sessions on my server, Netscape always tries to
resume them on the same day (and I shut down Netscape when going home :-).
You should however be aware, that there is no other means (besides restarting
Netscape) to get rid of a session from the client side.
[I personally would only recommend these long timeout values for "domestic"
aka 128bit ciphers, not for 40bit ciphers with possibly short (512bit)
RSA keys... Breaking 40bit keys within a day doesn't seem completele
unreasonable in the near future.]
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]
