Aloha,

As Michael Germony points out, the SSL Session ID can be renegotiated at
either the client or the server's will. It was not meant to map directly to
the arbitrary user concept of a "session" and so what Microsoft did in IE
5.x was only the catalyst to formally kill the SSL Session ID for the
purpose of application-specific session tracking without cookies or
URL-encoded IDs. As with most things in the Web, it worked fine for a while
although it probably should never have been done in the first place. It
apparently still works pretty well, but it isn't guaranteed to work or
continue to work.

> If you want a really secure stateful solution for HTTP sessions, start
> with SSL, use long, purely pseudo-randomly generated session IDs (no
hashing
> the user's IP, the current time, etc.) and use keep-alive.

Self-validating session IDs that are digitally signed by the server offer
the best solution. A unique number, the session ID, is hashed and the hash
encrypted using a key known only to the server. A symmetric key works fine,
though asymmetric may offer better resistance to cryptanalysis. The hash and
the encrypted hash are appended to the unique number. Thus forging session
IDs becomes computationally infeasible. Not to mention the very loud messy
noise that the brute force attack would make against the server. However,
dropping a digitally signed cookie in response to a GET request over HTTP
must never be thought of as secure -- not because encryption is not used,
that's obviously vulnerable to eavesdroppers/MITM -- but because of the
well-known potential for ill-mannered proxies to cache and distribute the
same Set-Cookie HTTP header to multiple clients. See MS KB Q263730:

http://support.microsoft.com/default.aspx?ID=KB;EN-US;Q263730&

Incidentally, MS did acknowledge the IE 5.x SSL Session ID issue as a "bug"
because it shortened the useful life of load balancing switches and other
existing deployments that do rely on the SSL Session ID for something
resembling short-lived secure session state management on the application
server side.

Here's the MS KB article:

http://support.microsoft.com/default.aspx?scid=KB;EN-US;q265369&

"Microsoft has confirmed this to be a problem in the Microsoft products that
are listed at the beginning of this article."

and

"NOTE: This problem does not occur in Microsoft Windows 2000 and Microsoft
Windows Millenium Edition"

Sincerely,

Jason Coombs
jasoncscience.org

-----Original Message-----
From: Kevin Spett [mailto:kspettspidynamics.com]
Sent: Thursday, July 25, 2002 11:33 AM
To: Ben Mord; webappsec securityfocus.com
Subject: Re: Coordinating SSL and session tracking layers to foil
session hijacking

    It's a really interesting idea, and it is a damn shame that the cookie
spec wasn't drawn up with the idea of PKI negotiation, but ultimately I
don't think it's possible to pull off. There are no webservers that I know
of (including Apache with mod_ssl) that have an API to expose that
information to software on higher levels. And if SSL is being done in
acceleration hardware, you can forget about it altogether. Even with an
open source operating system web server and SSL module, you'd be in for some
/major/ hacking.
    If you want a really secure stateful solution for HTTP sessions, start
with SSL, use long, purely pseudo-randomly generated session IDs (no hashing
the user's IP, the current time, etc.) and use keep-alive.

Kevin Spett
SPI Dynamics, Inc.
http://www.spidynamics.com/

----- Original Message -----
From: "Ben Mord" <bmordicon-nicholson.com>
To: "webappsec securityfocus.com" <webappsecsecurityfocus.com>
Sent: Thursday, July 25, 2002 2:52 PM
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 ]