Aloha,

It's my understanding that Microsoft killed SSL session ID
as the basis of server-side session state management.

http://www.sonicwall.com/ssl-center/ssl-acceleration.html

The bottom line is you need both SSL and cookie- or URL
name/value pair-encoded application-specific session ID.

Aloha & Mahalo,

Jason Coombs
jasoncscience.org

-----Original Message-----
From: Ben Mord [mailto:bmordicon-nicholson.com]
Sent: Thursday, July 25, 2002 8:53 AM
To: webappsec securityfocus.com
Subject: Coordinating SSL and session tracking layers to foil session
hijacking

As most readers on this list know, many web applications employ a session
tracking mechanism which set a cookie to a random identifier for that user
session. The user is then authenticated by other means, but once
authenticated, that cookie is then used to associate future user actions
with the user's identity. This session-tracking mechanism is usually
supplied by application server middleware such as a servlet engine, or an
ASP engine. It is exposed to the programmer as customizable server-side
"session variables" that automagically follow the user.

A completely separate application layer is often used to secure the traffic
with SSL. Because this service can not be completely delineated from
HTTP-level responsibilities, this SSL functionality is usually provided by
the web server and the resulting combination is called HTTPS.

Has anyone tried to get these two layers to talk to each other? We have two
concepts of a session here. At a lower level we have the SSL session, and at
a higher level we have the cookie-based concept of a session. Only one of
these two sessions was rigorously designed using cryptographic principles to
prevent hijacking. Unfortunately, this is not the one used by custom
application logic to enforce user-specific access control! Programmers use
the weaker, cookie-based concept.

The obvious solution is to get the session tracking mechanism to talk
directly to the SSL engine, so that it can use the SSL session instead of an
intrinsically weak cookie identifier. Am I missing here? The fact that you
can hijack a user session despite SSL by knowing the cookie (perhaps via
cross-site scripting) points to a simple flaw in the middleware. Cookies are
simply too general-purpose of a mechanism to serve such a critical role in
session security. The session key used in SSL, on the other hand, serves no
other purpose and is therefore highly optimized and protected. Getting the
SSL implementation to talk to the session-tracking mechanism should be
trivial for the vendors of these products - all that is needed is an
industry standard.

Is there a flaw in my logic somewhere, or do people agree with this
assessment? Is anyone aware of efforts to make this happen, or does anyone
have opinions about which industry organization is in the best position to
make this happen?

Thanks,
Ben

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]