Subject: SSL Session cache and IDs

From: "Bray, Mike" <[email-masked]>
Date: Mon, 25 Mar 2002 17:47:04 -0000

Can anyone help by explaining how the session cache works?  We have a web
site supported by two servers using a content switch to load balance.  The
content switch goes sticky on SSL id.  We are discovering that when two
people use SSL at the same time that towards the end of the SSL session the
content switch suddenly routes one session to the other machine thus causing
an error because the machine doesn't know anything about the session.

I have looked at the ssl_engine logs and found that it wants to give a
session a new id even though the user is sending requests within the
SSLCacheTimeout time.

Does the time out last from the start of the session to the end or does it
last from request to request?
Does the browser affect what happens?  I have seen discussion about
nokeepalive with MSIE.  Would this affect it?

Any help appreciated.

Mike Bray
SBS UK.
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Mads Toftum <[email-masked]>
Date: Mon, 25 Mar 2002 19:44:24 +0100

> session a new id even though the user is sending requests within the

and you're absolutely sure that it is not hte client that has requested
a new session? MSIE usually cuts sessions after a couple of minutes 
(the length varies with the browser and ssl version)
> last from request to request?

It should last from the start of the session until the timeout, but the
client can cut it short.

> Does the browser affect what happens? 

Ues, see above.

> I have seen discussion about
I don't think so.

vh

Mads Toftum
-- 
With a rubber duck, one's never alone.
              -- "The Hitchhiker's Guide to the Galaxy"
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Cliff Woolley <[email-masked]>
Date: Mon, 25 Mar 2002 14:21:12 -0500 (EST)

> > site supported by two servers using a content switch to load balance.
>

When load balancing, if the back-end servers do not share a session cache,
a client that initiates a session with one server and then gets handed off
to another server will lose the session, because the client will not know
it got handed off.  It will present a session to the new back-end server
that the new server knows nothing about, and the server will force a
renegotation.

> > Does the time out last from the start of the session to the end or
> > does it last from request to request?
>

The server can also cut it short.  This can happen in the above situation
or when the session cache fills up under heavy load (for certain kinds of
session caches).

> > I have seen discussion about nokeepalive with MSIE.  Would this affect
> > it?
> I don't think so.

I tend to think the two most likely are related.  There's less you can do
about it in this case, but the same general techniques might help.  What
BrowserMatch settings are you currently using?  How is your SessionCache
set up?

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   [email-masked]
   Apache HTTP Server Project

---

From: Mads Toftum <[email-masked]>
Date: Mon, 25 Mar 2002 21:00:50 +0100

> that the new server knows nothing about, and the server will force a

Yep, I read his post as if they had the load balancer set up with sticky
sessions - but you're probably right that it would be a good idea to test
without the loadbalancer, but with the same browser.
> or when the session cache fills up under heavy load (for certain kinds of

Yup, I forgot about that.
> BrowserMatch settings are you currently using?  How is your SessionCache
The defaults are nokeepalive IIRC - if that affects the session, then shouldn't
it cut the session short even after the initial request? Setting SSLLogLevel
to something like debug and looking for cache hits/misses would probably
be a good place to start. Also testing with something like Swamp and keeping
an eye out for session reuse.
I did some extensive testing on IE session lengt a year or two ago, and usually
they end up with something like cutting the session after 1 or 2 minutes
(this changes depending on the IE version, wether client certs are used and
wether it is SSLv2,3 or TLS). Testing with and without nokeepalive should be
easy though.

vh

Mads Toftum

---

From: Cliff Woolley <[email-masked]>
Date: Mon, 25 Mar 2002 15:10:26 -0500 (EST)

On Mon, 25 Mar 2002, Mads Toftum wrote:

> The defaults are nokeepalive IIRC - if that affects the session, then
> shouldn't it cut the session short even after the initial request?

nokeepalive doesn't really imply no session caching at all... that's not
exactly what I meant to say.  What I was trying to say was that IE doesn't
deal well with sessions in general, which is why kept-alive sessions cause
even more headaches -- IE just does bad things with them.  I can't be much
more specific than that because I haven't studied it in depth... but I
just feel like things that would make IE behave better with sessions in
general might make it do the right thing the server asks for a
renegotation in this case.

> Setting SSLLogLevel to something like debug and looking for cache
> hits/misses would probably be a good place to start.

This and testing with/without load balancing both sound like a good
plan...

--Cliff

   [email-masked]
   Charlottesville, VA