[3636] in WWW Security List Archive
Re: SSL sessions across stateless http?
daemon@ATHENA.MIT.EDU (Steen Larsen)
Tue Nov 26 12:49:26 1996
Date: Tue, 26 Nov 1996 16:12:37 +0100
From: Steen Larsen <steen.larsen@ed.nce.sita.int>
Reply-To: steen.larsen@ed.nce.sita.int
To: rgaloppini@tim.it
Cc: Jeff Lewis <lewis@netserver.Stanford.EDU>,
"Kennedy, John" <jdkennedy@cos.spaceapps1.spaceapps.com>,
www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
Roberto Galoppini wrote:
>
> Some of you wrote:
> >
> > > 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).
>
> and likely Jeff Lewis answered:
> >
> > 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.
>
> Did any of you sort out any detail on that session ID ? Is it the
> session key by any chance ? or what ?
> BTW I'm working on 'logical' session too and, so far, the better idea I
> got is create a random number at session setup, then pass it over from
> page to page as hidden-tag and, last but not least, use a time-stamp to
> allow
> end-user to use that random number for, let's say one hour.
> Use SSL above/under/besides is recomendeted.
(Note: My comments are based on the March draft of The SSL Protocol,
Version 3.0 - newer versions are available.
Chapter 7.1 on page 10 talks about session and state)
An SSL session is stateful. A session has a session ID which is
an arbitrary byte sequence chosen by the server. The session ID
is not a crypto key. A session also has a master secret which is
the result of a key exchange (RSA, Diffie-Hellman or Fortezza)
This was the session, for each session there may be several
connections. Each session has a server and a client random. It
also has a set of keys (finally, here are your keys!). The
keys used by server and client are different and there are
different keys for message authentication/integrity and
confidentiality. The keys are derived from the master secret.
So SSL seems to do exactly what you want. There should be no need
to do strange hacks on top of SSL. Now you just have
to work out how you can extract the SSL session ID and maybe
the SSL connection "server random" on your server script.
Best regards
Steen Larsen
--
Steen Koefoed Larsen <steen.larsen@ed.nce.sita.int>
Disclaimer: This letter may contain pure garbage that differs
from the opinion of myself and the companies I work for.
SITA -- Societe Internationale de Telecommunications Aeronautiqes
R & D Nice, Heraklion - 1041 Route des Dolines, F-06560 Valbonne
Phone: +33 4 92.96.63.67, Fax: +33 4 92.96.64.92, SITATEX: NCEEMXS
E-mail@home: steenkl@dircon.co.uk, GSM Mobile: +45 40512486
*** Syntax? Why not - they tax everything else! ***
