[3503] in WWW Security List Archive
Re: SSL sessions across stateless http?
daemon@ATHENA.MIT.EDU (Jeff Lewis)
Fri Nov 8 23:45:31 1996
To: "Kennedy, John" <jdkennedy@cos.spaceapps1.spaceapps.com>
Cc: www-security@ns2.rutgers.edu
Date: Fri, 08 Nov 1996 18:27:01 -0800
From: Jeff Lewis <lewis@netserver.Stanford.EDU>
Errors-To: owner-www-security@ns2.rutgers.edu
> Given that http is stateless, by what mechanism does SSL maintain a
> 'continuous' session across the many tcp/ip connections that can occur at
> a secured site? (I assume it's not a cookie).
The mechanism is a session id that the two parties figure out while
exchanging certificicates that they then use to encrypt messages to
each other. But it's really just a performance thing and if either
side doesn't cache session ids for whatever reason, they end up going
through the whole certificate exchange for every transaction. The
Stronghold apache server didn't cache session ids until recently and
got a huge performance boost when they did.
> If a client drops the 'connection' during an SSL session, how does the
> server determine when to end the session?
>
> Can the mechanism used by SSL be used by another application?
>...
We were looking at that, too, but either side can blow off using the
session id at any time, or it can just get bumped or expired from one
or the other's cache and then the two sides will end up renegotiating
and establishing a new one on the next connection, so multiple session
ids could end up getting used for each "session" at the application level.
That seemed to be enough of a complication for us that we just decided
to go with our own encrypted session ids in cookies or URLs.
If you look into it further and figure out how to make it work I'd
love to hear about it.
Jeff Lewis
lewis@stanford.edu
Distributed Computing Group, Stanford University
