I take it that the patch you referred to was the same patch as mentioned on
this bulletin?
http://www.microsoft.com/technet/security/bulletin/fq00-080.asp
-----Original Message-----
From: Imar Spaanjaars [mailto:e_mar@y...]
Sent: Friday, March 09, 2001 9:24 AM
To: Security_asp
Subject: RE: ASP Session ID and SSL - Again (Long)
I am afraid I haven't made myself very clear yet, but
the SSL app is already a VIRTUAL APPLICATION.
And indeed, IIS SHOULD create another session ID
because it thinks it is another application. This is
the crux of the whole situation: it SHOULD do that,
but it doesn't. I thought I had explained this already
a couple of times, but apparently I cannot clarify the
situation enough. (Or maybe your rephrase was too
short, and my long story was really necessary ;-)).
Out-of-process refers to the way IIS is setup. For
each "out-of-process" site, IIS will launch a new
process, therefore separating the various sites from
each other. This means that if site1 goes down,
because of overload, bugs, whatever, site2 and IIS can
still survive. MS has written quite a lot about this
subject, for example at:
http://msdn.microsoft.com/library/periodic/period97/IIs40.htm
(very old, but it discusses some important basics).
However, running a website in a different process than
IIS itself, will cause various problems related to
security because not everything is done under the
alias of IUSR_MachineName.
A couple of the side-effects of running a website
out-of-process are considered bugs (the fact that you
can't send mail through CDO with the build in SMTP
server is one of them) and may be solved with patches
and hotfixes.
But again, this is rather not where I am after. If I
can force IIS to hand out a new SessionID for EACH
APPLICATION my problems are solved, without having to
rely on tons of patches and other unforeseen problems.
Imar
> Turn the secured directory into a
> virtual(application) web on the server.
> IIS should create another session ID because it
> think it's another separate
> application? This is not a perfect idea, granted,
> but it wont require a lot
> of programming to fix either.
>