[3662] in WWW Security List Archive
Re: SSL sessions across stateless http?
daemon@ATHENA.MIT.EDU (Steen Larsen)
Tue Dec 3 14:04:21 1996
Date: Tue, 03 Dec 1996 18:15:49 +0100
From: Steen Larsen <steen.larsen@ed.nce.sita.int>
Reply-To: steen.larsen@ed.nce.sita.int
To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
Patrick C. Richard replied
Me:
>> Does anybody know an SSL WWW server that reveals the SSL session ID
>> to CGI scripts?
> That's kind of a bad thing because it can be re-negotiated at any time.
Isn't this normal for many types of session between two peers, anyone
can abort it at any time?
> If you are using SSL already, why not use the client certs to maintain
> state. That's what we recommend, anyhow.
This may be interesting, could you please explain further what you mean
with this? Sure the client cert establishes who I'm talking too, but it
doesn't enable me to follow a "session" on my server.
Hmm, maybe this discussion can't really continue until we define what
a session is or what Roberto wanted (remember this all started with a
question from Roberto)
Roberto Galoppini wrote:
> As far as I could see session id is sorted out when the two parties
> exchange certificates that they then use to encrypt messages. As
> somebody else wrote "it's really just a performance thing"
> and it can be renogotiated at any time (I ended up to read SSL spec
> right now, but expert like Bellovin confirmed it).
Again, what is a session generically? To me it is very often
"a performance thing". I'm sorry, but I have forgotten the original
purpose
of your session question.
By the way:
The IESG has approved the Internet-Draft "Proposed HTTP State
Management
Mechanism" <draft-ietf-http-state-mgmt-05.txt, .ps> as a Proposed
Standard. This document is the product of the HyperText Transfer
Protocol
Working Group. The IESG contact persons are Keith Moore and Harald
Alvestrand.
Technical Summary
This protocol extension defines a way for HTTP servers to ask clients
to maintain "per-session" state for them. This is accomplished by
having the server encode state information in a "cookie" which is
given to the client on an initial transaction, and which the client
includes along with future transaction requests for a particular set
of URIs (not necessarily to the same server as issued the original
cookie). Having clients keep state, especially across server
boundaries, is somewhat controversial, since it can violate users'
expectations of privacy. However, state management can be
accomplished even with vanilla HTTP by encoding "cookies" in URLs.
Explicit HTTP support for state management is preferable to that
alternative.
<snip>
Now we just have to find out how this integrates with the SSL security
fetaures.
Best regards
Steen
--
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! ***
