Groups | Blog | Home
all groups > iis security > january 2008 >

iis security : SSL 2.0


Smurfman
1/7/2008 1:07:02 PM
What is the best practice for suring up the security related to IIS and the
protocols that a website accepts?

Thanks
Smurfman
1/8/2008 6:08:04 AM
What I am learning is that by default, IIS allows lower secure protocols for
SSL. Meaning that although I specify that the server only accepts port 443
for SSL encryption, IIS can be configured to allow SSL 3.0 only and nothing
else instead of the weaker SSL 2.0

Does that help?

Thanks

BTW - IIS 6.0 on W2K3


[quoted text, click to view]
wjzhang@online.microsoft.com (
1/8/2008 7:29:42 AM
Hi,

To allow us be of assistance more efficiently, could you please be more
specific to the real issue you are facing currently?

For a web site on IIS, the only supported protocols should be HTTP and
HTTPS. If what you are interesting in is how to manage IIS web server
security, I suggest you take a look at the following chapters in the IIS
6.0 resource kit.

Part 1. Ch 3: Securing Web Sites and Applications
Part 2. Ch 5: Managing a Secure IIS 6.0 Solution

Internet Information Services (IIS) 6.0 Resource Kit
http://www.microsoft.com/downloads/details.aspx?familyid=80a1b6e6-829e-49b7-
8c02-333d9c148e69&displaylang=en

Again, if you have any specific question or concern, please don't hesitate
to post it here. We are pleased to be of help.

Have a nice day.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
Smurfman
1/9/2008 5:45:00 AM
Ahh, Cipher... I was close.. lol thanks a ton.

One last request - is there a Microsoft Best Practice to sure up a server,
should I be just disabling all but SSL3 ?

Thanks
J

[quoted text, click to view]
wjzhang@online.microsoft.com (
1/9/2008 10:47:54 AM
Yes, this is correct. We can control the supported ciphers for schannel by
modifying the registry. After you disable SSL2.0 and reboot the server, no
clients will be able to access the SSL site with SSL 2.0 protocol any more.

187498 How to disable PCT 1.0, SSL 2.0, SSL 3.0, or TLS 1.0 in Internet
Information Services
http://support.microsoft.com/default.aspx?scid=kb;EN-US;187498

To test if the setting has taken effect, you can simply specifiy the
protocol used by IE in Internet Options->Advanced and then browse to the
site to chreck the result.

Please let me know if you have any further question on this.

Have a nice day.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.


wjzhang@online.microsoft.com (
1/10/2008 7:56:27 AM
No, Microsoft hasn't suggested to enable SSL 3.0 only and disable all the
other ciphers. Only SSL 2.0 is not recommended for sure. The answer of your
question is fully based on your real scenario. If your web application has
quite critical concern on the security and consider only SSL 3.0 clients
should be allowed to access the site, then I believe it's fine to disable
the other ones.

Furthermore, TLS 1.0 and SSL 3.0 are quite smiliar protocols. You may look
through the following article:

What is TLS/SSL?
http://technet2.microsoft.com/windowsserver/en/library/ed5ae700-e05e-45ef-b5
36-45795dbb99a21033.mspx?mfr=true

Hope the info will be of some help. Have a nice day. :-)

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
Smurfman
1/10/2008 8:09:12 AM
In reading KB 187498 - I found a string that stated by default PCT is not
enabled on Windows 2003 Server.

However when I look at the key location as outlined in the KB

HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server

There is no values for the Enabled DWORD

Enabled with a DWORD value of 0x00000000 is disabled and 0xffffffff is
enabled according to KB 216482 -

So - since the value is not present by default, how is it that PCT is
disabled by default according to the aforementioned KBs?

Thanks


[quoted text, click to view]
David Wang
1/10/2008 12:39:48 PM
When you use the Windows API to read Registry keys, there is a
"default" value that is provided when the key does not exist.

Thus, the KB article is telling you that when there is no key, the
default value is disable (0).

How does one know if PCT is disabled by default? You either trust the
KB article or do your own test.

Can you clarify your question.


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







[quoted text, click to view]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
[quoted text, click to view]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
[quoted text, click to view]
Smurfman
1/10/2008 1:52:02 PM
Okay, I think I get what you are trying to say -

However, if the KB is telling me to disable for example SSL 2.0 to ADD a
DWORD called Enabled and assign it a value of 0x00000000 (0) to disable the
SCHANNEL protocol I would have expected to find a similar key already present
in the PCT 1.0 protocol if Windows 2003 Server is disabled by default.

In addition, ALL of the protocol values for default are not defined (value
not set)

Just want to make sure I am understanding the KB correctly.

How would preform a PCT 1.0 test? I can see where I can test the SSL 2.0 /
3.0 and TLS 1.0 in the Internet Explorer browser advanced settings... but
don't know how I might be able to do this for the PCL to see if in fact it is
disabled

Thanks


[quoted text, click to view]
David Wang
1/11/2008 12:34:25 AM
Default values are all defined in source code. They may not be
published, but not because of nefarious reasons.

For example, do you want Microsoft to publish a list of the millions
of "default" values for every single possible configuration switch in
Windows every time it ships a service pack? Does that even make sense?
But if Microsoft does not publish such a list, users can complain that
Microsoft is abusing its market position and withholding information.
See how users frequently paint things into a lose-lose situation? They
just want want want, even if they cannot use it.


As for why disabling some behaviors require setting Enabled=3D0 while
others are disabled by default and do not require such configuration
settings, here is one possible explanation which stems naturally from
software development.

<HYPOTHETICALLY>
Suppose in 2008 we have a feature SSL3 which is enabled by default and
SSL3.5 which is disabled by default in SCHANNEL because it conflicts
with SSL3 and is not yet popular. Now, fast forward to 2015, when SSL4
is introduced to be on by default because someone discovered a severe
security flaw in SSL3 in 2013.

What would the corresponding KB entry say?

To disable SSL3, you must set Enabled=3D0 in the registry.
To disable SSL3.5, you do nothing since it was disabled by default.

Now, you may argue "why not change the default value of SSL3 to be
disabled instead of requiring the user to set Enabled=3D0 in the
registry", but that's the problem with defaults. Some customer may
have purchased fixed systems in 2010 that only used SSL3 (which was
still viable at the time), and changing the default to disabled will
simply break those systems on upgrade UNLESS they remember to add the
Enabled=3Dffffffff registry key. How would you like it if on upgrades
Windows requires you to tweak 100 different values just to keep your
software functional? Hindsight is 20/20. Who knew in 2010 that SSL3
would be insecure?

Of course, if the default value of SSL3 is left alone, a user in 2015
may look at the instructions for disabling SSL3 and SSL3.5 and say
"hmm, I would have expected to find a similar key already present in
the SSL3.5 protocol if Windows 2015 Server is disabled [SSL3] by
default".

Now, another school of software design would have said "fill the
Registry with the current "default values" for each configuration
switch", so users can tell which are on and off by default and
everything looks congruent. While this design is open and leaves
nothing to question, it does not resolve the problem of "changing
default values" and only introduces legacy support costs for Microsoft
to maintain those values for the OS. As anyone in the software
business would agree, you want to introduce as little legacy as
possible to minimize support costs, so in terms of the costs of a
design choice, "hidden defaults" wins over "public defaults".

Note that this design choice is opposite of Open Source, which due to
its indifference of support costs (the user is responsible for support
-- go read the source code), it favors verbose configuration files and
public default values along with access to source code so that the
user can figure it out.

Is one necessarily better than the other? Not really. It all depends
on the user. For the casual user, too many choices is dangerous. For
the tinkerer, there are never enough choices.


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







[quoted text, click to view]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
[quoted text, click to view]
Smurfman
1/11/2008 6:55:03 AM
David thanks for your input on this. I appreciate your time, and what you
are saying.

One might argue then, why make the OS change in this case to disable PCT 1.0
by default from Windows 2000 Server to Windows 2003 Server. Again, if SSL
2.0 according to all the security experts is not good and is not secure, then
again, why not disabled it by default in Windows 2003 Server and KB woudl
read, hey if you have old web server software that needs to use SSL 2.0 then
you will need to enable the protocol - otherwise users will not be able to
connect. The idea I guess woudl be to harden the Default install - or a
service pack that would do this for you, rather than have someone find that
SSL 2.0 was being allowed.

I get what you are saying and true there is no perfect world. But lets face
it, in reality why do we have to keep poking around in the registry and
adding keys and changing things to make something secure. Why not patch IIS
to have a box that tells me what protocols within SSL I want to accept. And
true if in 2013 there was a serious flaw found in SSL 3.0 and in 2014 -
Windows 2014 Server was release I woudl expect that the SSL 3.0 would be
disabled by default.

Long and short of it, was unless I read this KB, I guess I wouldn't have
know about PCT.

I appreciate your input...

So that leaves me with - how do I test to see if SSL 2.0 is disabled or PCT
when attempting to hit my web server?

Thanks


[quoted text, click to view]
David Wang
1/11/2008 12:50:59 PM
Yes, this is the classic tradeoff between compatibility and security.

Believe me, the value of just about every single one of those settings
had a heated discussion (which is unfortunately not publicized
anywhere) between securing defaults and breaking people on upgrade vs
leaving defaults for people to tweak.

Basically, all the settings have gone through review of being "secure
by default" and teams have to provide rationale for anything perceived
as insecure -- usually a calculated risk-tradeoff for compatibility.

I suspect that the argument for SSL2 would have focused on the fact
that SSL3 would be chosen "by default" by most browsers and that users
who are using SSL2 have been doing so on their own choice for some
time now -- so it does not warrant changing the default value for SSL2
at all.

Now, you may view this as a security risk since the defaults are not
secure, but in reality the product team views this as a very
reasonable tradeoff between security and compatibility. The resulting
behavior is that no one is accidentally using SSL2 (so no security
risk) while those intentionally use SSL2 are not broken on upgrade. A
sort of "best of both worlds" compromise.

Yes, this compromise will never satisfy the ideological zealot which
wants "secure defaults", but consider this -- it may not be worth it
to anger 80% of users broken by an upgrade to satisfy the zeal of 20%
of users. Always keep this in mind.

Now, the decision is always case-by-case -- I'm just giving you the
rationale where compatibility wins over changed secure defaults -- but
most of the time in Windows Server 2003 breaking security changes were
made.

I understand your expectation that if a serious flaw is found in SSL3
that you'd expect it to be disabled by default, but believe me there
would be a big discussion in Microsoft about changing that default --
it is unfortunate that you never see the passionate arguments on both
sides for the change -- you only see the end result and think either
"yes, Microsoft secured the default" or "Microsoft screwed up security
by default *again*" -- most choices are simply not as easy as you
think, and it is hard to please everyone regardless if you give them a
choice or not.

Regarding the SSL selection UI in IIS -- that is a good idea, but
there are several problems with such a proposal such that it will
likely never happen. You are asking the IIS team to take
responsibility to make/depend on an UI provided by the SCHANNEL team
to introduce knobs into the IIS UI which make little difference to 90+
% of users. By definition, such configuration do not get prime
treatment in the UI and go to the registry -- where those that care
about security can tweak to their hearts content. Basically, I do not
see giving the 1% user preferential treatment in the UI to override
secured defaults in the OS and confusing the other 99% user to be a
good idea.

Remember, proper UI design is not about giving access to all the
choices -- it is about giving access to the *right* choices. Balancing
security, compatibility, and usability is HARD, especially for a
widely used product like IIS.


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






[quoted text, click to view]
AddThis Social Bookmark Button