Yuck! Thank you, Microsoft. Not a bug, yeah right... they just broke one of
the intended purposes of SSL - continuous authentication between strangers.
(Jason Coombs also forwarded an article about this issue, which you probably
didn't receive before sending this email.)

Well this is a great situation. We're forced to use an obviously flawed
authentication protocol, even though it was the purpose of SSL to do this
for us in the first place. The ugly part is the only way to fix this is on
the client side. We could invent yet another secure protocol (e.g. the
browser could always set a HTTP header field to a hash of its entire HTTP
GET or POST request), implement this in new browsers, and then wait for the
old browsers to die out... Or, Microsoft could just fix their "feature", and
we could wait for IE 5.x to die. I guess the latter is the direction we'll
go. Assuming no more SSL bugs in popular browsers, we can switch to SSL
session IDs in a few years. It looks like this particular act of Microsoft
brilliance just set us back by about 5-7 years or so in the area of
authentication.

-----Original Message-----
From: Gabriel Lawrence [mailto:gabebutterflysecurity.com]
Sent: Thursday, July 25, 2002 4:51 PM
To: Ben Mord
Cc: webappsec securityfocus.com
Subject: Re: Coordinating SSL and session tracking layers to foil
sessionhijacking

Not to bash IE, but it has a bug that expires the SSL session ID very
frequently, often before you even get back to the server after the first
request.

We had tried to use SSL session ids to manage sticky sessions through a
load balancer once and it just turned out not to be possible. This was
with IE 5.x I think, and MSFT had classified this as not a bug...

-gabe

On Thu, 2002-07-25 at 11:52, Ben Mord wrote:
>
> 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.
>

--
Gabriel Lawrence
CTO
Butterfly Security <www.butterflysecurity.com>
(408) 333-9948
gabebutterflysecurity.com

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