IIS and SSL flaw...

We have a web-serve with IIS 6.0 on Server 2003.
SSL is enabled, and the appropriate folders are check-marked to require SSL
communication.
Our problem is this:
If SSL is enabled for the site (http://mysite/) under folders (/IT/) and
(/fred/) then SSL works for the designated folders.
The flaw is that you can also browse to the root-site in SSL, as well.
(https://mysite/).
Since we're using 8192-bit encryption, we're afraid of a mass request for
SSL connections crashing the server, since a specified folder is not required
in the address. (A malicious user can just use the root-site in the address
bar...)
How do we address/fix this issue, without disabling SSL for ecnryption?
Note: Please read my issue before referencing a "Intro to IIS" page or
"Common Issues" page, since I have already tried this route; they do not
address the issue that I'm discussing.

Re: IIS and SSL flaw...

This is not a flaw, and unfortunately, there is really nothing you can
do about it.

SSL provides encryption between two endpoints identified via IP:Port.
Specifically, SSL does not distinguish between URLs nor Host header.
Thus, it is impossible to force SSL for /IT/ and /fred/ but not /.

Why? Let's think about the sequence of events on an SSL request:
1. Client connects to IP:Port and negotiates SSL
2. Certificates are exchanged, encryption key is determined, and
network packet is encrypted by the client and sent to the server
3. Server starts decrypting 8192bit to determine details like Host
header or URL, and the rest of request processing continues.

Notice that at the point of starting to decrypt 8192bit, server does
not know the Host header nor URL, hence it cannot use the URL to
decide if it should continue decrypting requests to /IT/ and /fred/
while rejecting / . It is the classic SSL Catch-22.

Now, if SSL encryption worked like HTTP compression, where only the
entity body is compressed, then what you want to do is perfectly
possible. But, that's not how SSL works... and what you want to do is
impossible.

I commend you for considering security ramifications of enabling
8192bit SSL. However, I do not think your approach of refusing SSL
on / but allowing SSL on /IT/ and /fred/ is valid security. What you
are doing is essentially a very weak form of authentication, where
access to 8192bit SSL is granted if the user knows the URL. Security
analysis always assumes the adversary can determine the URL; hence
what you want to do is not secure.

The only thing I think you can do is use hardware acceleration to make
8192bit SSL be faster so that the cost of DoS is lower.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Mar 1, 2:13 am, dba-tamuk
wrote:
> We have a web-serve with IIS 6.0 on Server 2003.
> SSL is enabled, and the appropriate folders are check-marked to require SSL
> communication.
> Our problem is this:
> If SSL is enabled for the site (http://mysite/) under folders (/IT/) and
> (/fred/) then SSL works for the designated folders.
> The flaw is that you can also browse to the root-site in SSL, as well.
> (https://mysite/).
> Since we're using 8192-bit encryption, we're afraid of a mass request for
> SSL connections crashing the server, since a specified folder is not required
> in the address. (A malicious user can just use the root-site in the address
> bar...)
> How do we address/fix this issue, without disabling SSL for ecnryption?
> Note: Please read my issue before referencing a "Intro to IIS" page or
> "Common Issues" page, since I have already tried this route; they do not
> address the issue that I'm discussing.

Re: IIS and SSL flaw...

Thanks for the info.
Just to let ya know, I've set up domain access rights on the folders in
question. Users login, via Windows Authentication through the SSL.
It sucks that SSL/TLS contains that flaw... I wanted to point out the flaw
to Microsoft, and see if they could at least address the issue; alas, as a
college student/worker, I don't make enough to pay the initial $265 or
whatever it is.
Granted, this could be considered a user-operability request, rather than a
kb issue...
Is there a way I can address this to Microsoft, without paying that hefting
fine/assessment fee?
Thansk for the help again; and it sucks that SSL can't be addressed like
HTTP compression.


"David Wang" wrote:

> This is not a flaw, and unfortunately, there is really nothing you can
> do about it.
>
> SSL provides encryption between two endpoints identified via IP:Port.
> Specifically, SSL does not distinguish between URLs nor Host header.
> Thus, it is impossible to force SSL for /IT/ and /fred/ but not /.
>
> Why? Let's think about the sequence of events on an SSL request:
> 1. Client connects to IP:Port and negotiates SSL
> 2. Certificates are exchanged, encryption key is determined, and
> network packet is encrypted by the client and sent to the server
> 3. Server starts decrypting 8192bit to determine details like Host
> header or URL, and the rest of request processing continues.
>
> Notice that at the point of starting to decrypt 8192bit, server does
> not know the Host header nor URL, hence it cannot use the URL to
> decide if it should continue decrypting requests to /IT/ and /fred/
> while rejecting / . It is the classic SSL Catch-22.
>
> Now, if SSL encryption worked like HTTP compression, where only the
> entity body is compressed, then what you want to do is perfectly
> possible. But, that's not how SSL works... and what you want to do is
> impossible.
>
> I commend you for considering security ramifications of enabling
> 8192bit SSL. However, I do not think your approach of refusing SSL
> on / but allowing SSL on /IT/ and /fred/ is valid security. What you
> are doing is essentially a very weak form of authentication, where
> access to 8192bit SSL is granted if the user knows the URL. Security
> analysis always assumes the adversary can determine the URL; hence
> what you want to do is not secure.
>
> The only thing I think you can do is use hardware acceleration to make
> 8192bit SSL be faster so that the cost of DoS is lower.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
> On Mar 1, 2:13 am, dba-tamuk
> wrote:
> > We have a web-serve with IIS 6.0 on Server 2003.
> > SSL is enabled, and the appropriate folders are check-marked to require SSL
> > communication.
> > Our problem is this:
> > If SSL is enabled for the site (http://mysite/) under folders (/IT/) and
> > (/fred/) then SSL works for the designated folders.
> > The flaw is that you can also browse to the root-site in SSL, as well.
> > (https://mysite/).
> > Since we're using 8192-bit encryption, we're afraid of a mass request for
> > SSL connections crashing the server, since a specified folder is not required
> > in the address. (A malicious user can just use the root-site in the address
> > bar...)
> > How do we address/fix this issue, without disabling SSL for ecnryption?
> > Note: Please read my issue before referencing a "Intro to IIS" page or
> > "Common Issues" page, since I have already tried this route; they do not
> > address the issue that I'm discussing.
>
>
>

Re: IIS and SSL flaw...

> Is there a way I can address this to Microsoft,
> without paying that hefting fine/assessment fee?

The fee is to prevent freeloaders from abusing Microsoft support as
front-line tech support for their proprietary systems that happen to
run on Windows or use IIS.

Bug Reports are always free -- you get charged the fee up front and
then upon bug submission, the fee is refunded to you.

There are thousands of avenues to make feature requests. However,
finding the correct avenue is unfortunately way harder than it should.

SSL used by IIS is provided by HTTP.SYS, and their team blog is at:
http://blogs.msdn.com/wndp/

IIS team hosts its web presence at: http://www.iis.net , so you can
comment there -- though as I note, SSL is something provided by
HTTP.SYS, so IIS will only be making an indirect feature request to
HTTP.SYS team.

Unfortunately, the "flaw" is really caused by SSL's utilization, and
short of rewriting the SSL specification and replacing every web
server and web browser software in the world, there is nothing
Microsoft or anyone can do.

SSL operates at the TCP layer to secure communications between IP:Port
endpoints.

URLs and Compression exist at the HTTP layer on TOP of TCP.

Thus it is impossible to parameterize TCP level operations based on
HTTP level concepts because you have to go through TCP to get to HTTP.

Compression is an HTTP-level concept because the HTTP spec says that
it is merely an encoding/transformation of HTTP Entity Body, denoted
through the Content-Encoding header.

Most people mistakenly imagine that SSL is also an encoding/
transformation of HTTP Entity Body (i.e. just encrypting the Username/
password Form POSTs)... when in fact SSL is a transformation of the
entire TCP packet which carries HTTP as payload.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//





On Mar 3, 12:49 am, dba-tamuk
wrote:
> Thanks for the info.
> Just to let ya know, I've set up domain access rights on the folders in
> question. Users login, via Windows Authentication through the SSL.
> It sucks that SSL/TLS contains that flaw... I wanted to point out the flaw
> to Microsoft, and see if they could at least address the issue; alas, as a
> college student/worker, I don't make enough to pay the initial $265 or
> whatever it is.
> Granted, this could be considered a user-operability request, rather than a
> kb issue...
> Is there a way I can address this to Microsoft, without paying that hefting
> fine/assessment fee?
> Thansk for the help again; and it sucks that SSL can't be addressed like
> HTTP compression.
>
>
>
> "David Wang" wrote:
> > This is not a flaw, and unfortunately, there is really nothing you can
> > do about it.
>
> > SSL provides encryption between two endpoints identified via IP:Port.
> > Specifically, SSL does not distinguish between URLs nor Host header.
> > Thus, it is impossible to force SSL for /IT/ and /fred/ but not /.
>
> > Why? Let's think about the sequence of events on an SSL request:
> > 1. Client connects to IP:Port and negotiates SSL
> > 2. Certificates are exchanged, encryption key is determined, and
> > network packet is encrypted by the client and sent to the server
> > 3. Server starts decrypting 8192bit to determine details like Host
> > header or URL, and the rest of request processing continues.
>
> > Notice that at the point of starting to decrypt 8192bit, server does
> > not know the Host header nor URL, hence it cannot use the URL to
> > decide if it should continue decrypting requests to /IT/ and /fred/
> > while rejecting / . It is the classic SSL Catch-22.
>
> > Now, if SSL encryption worked like HTTP compression, where only the
> > entity body is compressed, then what you want to do is perfectly
> > possible. But, that's not how SSL works... and what you want to do is
> > impossible.
>
> > I commend you for considering security ramifications of enabling
> > 8192bit SSL. However, I do not think your approach of refusing SSL
> > on / but allowing SSL on /IT/ and /fred/ is valid security. What you
> > are doing is essentially a very weak form of authentication, where
> > access to 8192bit SSL is granted if the user knows the URL. Security
> > analysis always assumes the adversary can determine the URL; hence
> > what you want to do is not secure.
>
> > The only thing I think you can do is use hardware acceleration to make
> > 8192bit SSL be faster so that the cost of DoS is lower.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Mar 1, 2:13 am, dba-tamuk
> > wrote:
> > > We have a web-serve with IIS 6.0 on Server 2003.
> > > SSL is enabled, and the appropriate folders are check-marked to require SSL
> > > communication.
> > > Our problem is this:
> > > If SSL is enabled for the site (http://mysite/) under folders (/IT/) and
> > > (/fred/) then SSL works for the designated folders.
> > > The flaw is that you can also browse to the root-site in SSL, as well.
> > > (https://mysite/).
> > > Since we're using 8192-bit encryption, we're afraid of a mass request for
> > > SSL connections crashing the server, since a specified folder is not required
> > > in the address. (A malicious user can just use the root-site in the address
> > > bar...)
> > > How do we address/fix this issue, without disabling SSL for ecnryption?
> > > Note: Please read my issue before referencing a "Intro to IIS" page or
> > > "Common Issues" page, since I have already tried this route; they do not
> > > address the issue that I'm discussing.- Hide quoted text -
>
> - Show quoted text -

Re: IIS and SSL flaw...

It might perhaps be better for you implement https detection on
your pages where you do not want to expend the cpu, and then
issue a redirect response so that the client re-hits via http, and
presumably will then continue with http in its subsequent hits.
(note that I did not say to use server transfer)

As David points out, this is not a flaw in implementation, which
is in accord with the defined stds for ssl, but rather this is a desire
on your part to have a feature that would absolve you of the need
to manage redirects.

Roger
"dba-tamuk" wrote in message
news:2C6CA9E6-B92C-4DAB-A4EC-D5989DD0CA7D@microsoft.com...
> Thanks for the info.
> Just to let ya know, I've set up domain access rights on the folders in
> question. Users login, via Windows Authentication through the SSL.
> It sucks that SSL/TLS contains that flaw... I wanted to point out the flaw
> to Microsoft, and see if they could at least address the issue; alas, as a
> college student/worker, I don't make enough to pay the initial $265 or
> whatever it is.
> Granted, this could be considered a user-operability request, rather than
> a
> kb issue...
> Is there a way I can address this to Microsoft, without paying that
> hefting
> fine/assessment fee?
> Thansk for the help again; and it sucks that SSL can't be addressed like
> HTTP compression.
>
>
> "David Wang" wrote:
>
>> This is not a flaw, and unfortunately, there is really nothing you can
>> do about it.
>>
>> SSL provides encryption between two endpoints identified via IP:Port.
>> Specifically, SSL does not distinguish between URLs nor Host header.
>> Thus, it is impossible to force SSL for /IT/ and /fred/ but not /.
>>
>> Why? Let's think about the sequence of events on an SSL request:
>> 1. Client connects to IP:Port and negotiates SSL
>> 2. Certificates are exchanged, encryption key is determined, and
>> network packet is encrypted by the client and sent to the server
>> 3. Server starts decrypting 8192bit to determine details like Host
>> header or URL, and the rest of request processing continues.
>>
>> Notice that at the point of starting to decrypt 8192bit, server does
>> not know the Host header nor URL, hence it cannot use the URL to
>> decide if it should continue decrypting requests to /IT/ and /fred/
>> while rejecting / . It is the classic SSL Catch-22.
>>
>> Now, if SSL encryption worked like HTTP compression, where only the
>> entity body is compressed, then what you want to do is perfectly
>> possible. But, that's not how SSL works... and what you want to do is
>> impossible.
>>
>> I commend you for considering security ramifications of enabling
>> 8192bit SSL. However, I do not think your approach of refusing SSL
>> on / but allowing SSL on /IT/ and /fred/ is valid security. What you
>> are doing is essentially a very weak form of authentication, where
>> access to 8192bit SSL is granted if the user knows the URL. Security
>> analysis always assumes the adversary can determine the URL; hence
>> what you want to do is not secure.
>>
>> The only thing I think you can do is use hardware acceleration to make
>> 8192bit SSL be faster so that the cost of DoS is lower.
>>
>>
>> //David
>> http://w3-4u.blogspot.com
>> http://blogs.msdn.com/David.Wang
>> //
>>
>>
>>
>>
>> On Mar 1, 2:13 am, dba-tamuk
>> wrote:
>> > We have a web-serve with IIS 6.0 on Server 2003.
>> > SSL is enabled, and the appropriate folders are check-marked to require
>> > SSL
>> > communication.
>> > Our problem is this:
>> > If SSL is enabled for the site (http://mysite/) under folders (/IT/)
>> > and
>> > (/fred/) then SSL works for the designated folders.
>> > The flaw is that you can also browse to the root-site in SSL, as well.
>> > (https://mysite/).
>> > Since we're using 8192-bit encryption, we're afraid of a mass request
>> > for
>> > SSL connections crashing the server, since a specified folder is not
>> > required
>> > in the address. (A malicious user can just use the root-site in the
>> > address
>> > bar...)
>> > How do we address/fix this issue, without disabling SSL for ecnryption?
>> > Note: Please read my issue before referencing a "Intro to IIS" page or
>> > "Common Issues" page, since I have already tried this route; they do
>> > not
>> > address the issue that I'm discussing.
>>
>>
>>