I don't think this would work as you think in the practical application.

In brief,
The session key is used to bypass the expensive portion of the crypto.
When a client presents a session key it is assumed that the client knows
the previously negotiated symetric key. Should this actually be the case
the symetric key should then be used to immediately negotiate and
exchange a new symetric key. Should this not be the case then all of the
keys should be discarded and a full renegotiation will have to occur, in
this case a new session key is supposed to be issued to represent the
new negotiated session.

Unless you are using client certificates the new negotiation would have
no way to properly identify the user without having to ask for
authentication again. Doing this would create a burden on your users,
not doing this allows for hijacking to occur by presenting session keys
and waiting to hit a valid one. As a side effect of this you could also
end up with a nice DOS if the requestor has more computational power or
has pre-computed the session keys. Hardware acceleration would help but
not solve the problem. In the end you would have what appears to be a
random failure of authentication for subsets of users when you were
being attacked as the collided with session keys in use.

HTH,
Jason.

Ben Mord wrote:
>
> 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

-- 
#!/usr/local/bin/perl
  print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);

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