There are some possibilities, but first I must point out a few things about SSL which make what you want to do a bit difficult, even though I don't understand why you want to, but that later.

SSL SESSID is not encrypted and sits in a portion of the L5 header. It is in clear text which means it is not secure. The upside though is that it doesn't matter because even if you hijacked the conn via TCP and forged the SSL SESSID correctly, your payload would be garbage unless you also cracked the cypher...

BUT next, is the fact that SESSID can be renegotiated at will by either the client or server. Internet Explorer 5, 5.1 and 5.5 were modified by MS to force a key (and session) renegotiation every two minutes. So during the session a client could have many different SSL session ID's...

granted, a server side CGI or Object if properly written could possibly pick up the sessionID at L5, but you'd be bumping the stack which is no small effort (at least to me).

Besides, if youre are already in SSL, why be so concerned about cookie delivered sess id's? If you're in SSL the cookie is encrypted...

FWIW
Mike

>>> Ben Mord <bmordicon-nicholson.com> 07/25/02 02:52PM >>>
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 ]