Am I missing something here? It seems like, although not necessary, the
IE 5.x "bug" isn't such a bad thing. As Mike Gemony pointed out, if
you're using SSL, then cookies are encrypted anyway; so you should be
able to use cookies for session IDs without having to worry about people
stealing them. So why even bother to think about the SSL session ID?
When I develop web apps for secure servers, I even develop them on a
non-secure server first, and then just copy it over since SSL is
invisible to the programmer. Unless there's something wrong with what
I'm thinking, I don't really see the issue.

Bryan Ponnwitz
Webmaster - Broome-Tioga Boces
bponnwitbtboces.org
(607) 763-3609

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