[3703] in WWW Security List Archive
Re: SSL sessions across stateless http?
daemon@ATHENA.MIT.EDU (Patrick C. Richard)
Wed Dec 4 19:23:34 1996
Date: Wed, 4 Dec 1996 13:59:51 -0800 (PST)
From: "Patrick C. Richard" <patr@xcert.com>
To: Steen Larsen <steen.larsen@ed.nce.sita.int>
cc: www-security@ns2.rutgers.edu
In-Reply-To: <32A46045.3FC0@ed.nce.sita.int>
Errors-To: owner-www-security@ns2.rutgers.edu
On Tue, 3 Dec 1996, Steen Larsen wrote:
> Date: Tue, 03 Dec 1996 18:15:49 +0100
> From: Steen Larsen <steen.larsen@ed.nce.sita.int>
> To: www-security@ns2.rutgers.edu
> Subject: Re: SSL sessions across stateless http?
>
> 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?
Yes, but SSL session ID's are renegotiated *a lot*.
> > 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.
We are assuming that the application has an integrated PKI (if it doesn't,
it isn't worth it's salt as a secure app because it won't check CRLs, etc).
We are saying that you can use the integrated PKI to also store other things.
I am also saying that your client cert is the best session identifier
that you can have.
>
> 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! ***
>
----
Pat Richard
patr@x509.com
