SSL 2.0

What is the best practice for suring up the security related to IIS and the
protocols that a website accepts?

Thanks

RE: SSL 2.0

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=80a 1b6e6-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/de fault.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.

RE: SSL 2.0

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


""WenJun Zhang[msft]"" wrote:

> 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=80a 1b6e6-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/de fault.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.
>
>

RE: SSL 2.0

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;1874 98

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/de fault.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.

RE: SSL 2.0

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

""WenJun Zhang[msft]"" wrote:

> 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;1874 98
>
> 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/de fault.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.
>
>
>
>

RE: SSL 2.0

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/ed5ae 700-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/de fault.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.

RE: SSL 2.0

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\SCHA NNEL\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


""WenJun Zhang[msft]"" wrote:

> 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/ed5ae 700-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/de fault.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.
>
>

Re: SSL 2.0

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
//







On Jan 10, 8:09=A0am, Smurfman wrote:
> 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\SCHA NNEL\Protocols=
\=ADPCT 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
>
>
>
> ""WenJun Zhang[msft]"" wrote:
> > No, Microsoft hasn't suggested to enable SSL 3.0 only and disable all th=
e
> > other ciphers. Only SSL 2.0 is not recommended for sure. The answer of y=
our
> > question is fully based on your real scenario. If your web application h=
as
> > 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 disabl=
e
> > the other ones.
>
> > Furthermore, TLS 1.0 and SSL 3.0 are quite smiliar protocols. You may lo=
ok
> > through the following article:
>
> > What is TLS/SSL?
> >http://technet2.microsoft.com/windowsserver/en/library/ed5a e700-e05e-...
> > 36-45795dbb99a21033.mspx?mfr=3Dtrue
>
> > Hope the info will be of some help. Have a nice day. :-)
>
> > Sincerely,
>
> > WenJun Zhang
>
> > Microsoft Online Community Support
>
> > ==================== =====
==================== =====3D=
=3D
>
> > Get notification to my posts through email? Please refer to:
> >http://msdn.microsoft.com/subscriptions/managednewsgroups/d efault.asp...
> > ications.
>
> > Note: The MSDN Managed Newsgroup support offering is for non-urgent issu=
es
> > where an initial response from the community or a Microsoft Support
> > Engineer within 1 business day is acceptable. Please note that each foll=
ow
> > up response may take approximately 2 business days as the support
> > professional working with you may need further investigation to reach th=
e
> > most efficient resolution. The offering is not appropriate for situation=
s
> > that require urgent, real-time or phone-based interactions or complex
> > project analysis and dump analysis issues. Issues of this nature are bes=
t
> > handled working with a dedicated Microsoft Support Engineer by contactin=
g
> > Microsoft Customer Support Services (CSS) at:
>
> >http://msdn.microsoft.com/subscriptions/support/default.asp x.
>
> > ==================== =====
==================== =====3D=
=3D
>
> > This posting is provided "AS IS" with no warranties, and confers no righ=
ts.- Hide quoted text -
>
> - Show quoted text -

Re: SSL 2.0

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


"David Wang" wrote:

> 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
> //
>
>
>
>
>
>
>
> On Jan 10, 8:09 am, Smurfman wrote:
> > 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\SCHA NNEL\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
> >
> >
> >
> > ""WenJun Zhang[msft]"" wrote:
> > > 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/ed5a e700-e05e-...
> > > 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/d efault.asp...
> > > 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.asp x.
> >
> > > ==================================================
> >
> > > This posting is provided "AS IS" with no warranties, and confers no rights.- Hide quoted text -
> >
> > - Show quoted text -
>
>

Re: SSL 2.0

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.


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
//







On Jan 10, 1:52=A0pm, Smurfman wrote:
> 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 th=
e
> SCHANNEL protocol I would have expected to find a similar key already pres=
ent
> 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
>
>
>
> "David Wang" wrote:
> > 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
> > //
>
> > On Jan 10, 8:09 am, Smurfman wrote:
> > > 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\SCHA NNEL\Proto=
cols\­­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
>
> > > ""WenJun Zhang[msft]"" wrote:
> > > > No, Microsoft hasn't suggested to enable SSL 3.0 only and disable al=
l 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 applicati=
on has
> > > > quite critical concern on the security and consider only SSL 3.0 cli=
ents
> > > > should be allowed to access the site, then I believe it's fine to di=
sable
> > > > the other ones.
>
> > > > Furthermore, TLS 1.0 and SSL 3.0 are quite smiliar protocols. You ma=
y look
> > > > through the following article:
>
> > > > What is TLS/SSL?
> > > >http://technet2.microsoft.com/windowsserver/en/library/ed5a e700-e05e-=
....
> > > > 36-45795dbb99a21033.mspx?mfr=3Dtrue
>
> > > > Hope the info will be of some help. Have a nice day. :-)
>
> > > > Sincerely,
>
> > > > WenJun Zhang
>
> > > > Microsoft Online Community Support
>
> > > > ==================== ===
==================== =====3D=
===3D
>
> > > > Get notification to my posts through email? Please refer to:
> > > >http://msdn.microsoft.com/subscriptions/managednewsgroups/d efault.asp=
....
> > > > 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 reac=
h the
> > > > most efficient resolution. The offering is not appropriate for situa=
tions
> > > > that require urgent, real-time or phone-based interactions or comple=
x
> > > > project analysis and dump analysis issues. Issues of this nature are=
best
> > > > handled working with a dedicated Microsoft Support Engineer by conta=
cting
> > > > Microsoft Customer Support Services (CSS) at:
>
> > > >http://msdn.microsoft.com/subscriptions/support/default.asp x.
>
> > > > ==================== ===
==================== =====3D=
===3D
>
> > > > This posting is provided "AS IS" with no warranties, and confers no =
rights.- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Re: SSL 2.0

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


"David Wang" wrote:

> 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=0 while
> others are disabled by default and do not require such configuration
> settings, here is one possible explanation which stems naturally from
> software development.
>
>
> 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=0 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=0 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=ffffffff 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
> //
>
>
>
>
>
>
>
> On Jan 10, 1:52 pm, Smurfman wrote:
> > 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
> >
> >
> >
> > "David Wang" wrote:
> > > 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
> > > //
> >
> > > On Jan 10, 8:09 am, Smurfman wrote:
> > > > 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\SCHA NNEL\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
> >
> > > > ""WenJun Zhang[msft]"" wrote:
> > > > > 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/ed5a e700-e05e-....
> > > > > 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/d efault.asp....
> > > > > 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.asp x.
> >
> > > > > ==================================================
> >
> > > > > This posting is provided "AS IS" with no warranties, and confers no rights.- Hide quoted text -
> >
> > > > - Show quoted text -- Hide quoted text -
> >
> > - Show quoted text -
>
>

Re: SSL 2.0

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
//






On Jan 11, 6:55=A0am, Smurfman wrote:
> David thanks for your input on this. =A0I appreciate your time, and what y=
ou
> are saying. =A0
>
> 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. =A0Again, if S=
SL
> 2.0 according to all the security experts is not good and is not secure, t=
hen
> 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 th=
en
> you will need to enable the protocol - otherwise users will not be able to=

> connect. =A0The 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 tha=
t
> SSL 2.0 was being allowed.
>
> I get what you are saying and true there is no perfect world. But lets fac=
e
> it, in reality why do we have to keep poking around in the registry and
> adding keys and changing things to make something secure. =A0Why not patch=
IIS
> to have a box that tells me what protocols within SSL I want to accept. =
=A0And
> 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 PC=
T
> when attempting to hit my web server?
>
> Thanks
>
>
>
> "David Wang" wrote:
> > 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.
>
> >
> > 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
> > //
>
> > On Jan 10, 1:52 pm, Smurfman wrote:
> > > 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 disabl=
e 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 (v=
alue
> > > 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 fac=
t it is
> > > disabled
>
> > > Thanks
>
> > > "David Wang" wrote:
> > > > 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 th=
e
> > > > KB article or do your own test.
>
> > > > Can you clarify your question.
>
> > > > //David
> > > >http://w3-4u.blogspot.com
> > > >http://blogs.msdn.com/David.Wang
> > > > //
>
> > > > On Jan 10, 8:09 am, Smurfman wrote:
> > > > > 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\SCHA NNEL\P=
rotocols\­­=ADPCT 1.0\Server
>
> > > > > There is no values for the Enabled DWORD
>
> > > > > Enabled with a DWORD value of 0x00000000 is disabled and 0xfffffff=
f 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
>
> > > > > ""WenJun Zhang[msft]"" wrote:
> > > > > > No, Microsoft hasn't suggested to enable SSL 3.0 only and disabl=
e all the
> > > > > > other ciphers. Only SSL 2.0 is not recommended for sure. The ans=
wer of your
> > > > > > question is fully based on your real scenario. If your web appli=
cation 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 t=
o disable
> > > > > > the other ones.
>
> > > > > > Furthermore, TLS 1.0 and SSL 3.0 are quite smiliar protocols. Yo=
u may look
> > > > > > through the following article:
>
> > > > > > What is TLS/SSL?
> > > > > >http://technet2.microsoft.com/windowsserver/en/library/ed5a e700-e=
05e-....
> > > > > > 36-45795dbb99a21033.mspx?mfr=3Dtrue
>
> > > > > > Hope the info will be of some help. Have a nice day. :-)
>
> > > > > > Sincerely,
>
> > > > > > WenJun Zhang
>
> > > > > > Microsoft Online Community Support
>
> > > > > > ==================== =3D=
==================== =====3D=
====
>
> > > > > > Get notification to my posts through email? Please refer to:
> > > > > >http://msdn.microsoft.com/subscriptions/managednewsgroups/d efault=
..asp....
> > > > > > ications.
>
> > > > > > Note: The MSDN Managed Newsgroup support offering is for non-urg=
ent issues
> > > > > > where an initial response from the community or a Microsoft Supp=
ort
> > > > > > Engineer within 1 business day is acceptable. Please note that e=
ach follow
> > > > > > up response may take approximately 2 business days as the suppor=
t
> > > > > > professional working with you may need further investigation to =
reach the
> > > > > > most efficient resolution. The offering is not appropriate for s=
ituations
> > > > > > that require urgent, real-time or phone-based interactions or co=
mplex
> > > > > > project analysis and dump analysis issues. Issues of this nature=
are best
> > > > > > handled working with a dedicated Microsoft Support Engineer by c=
ontacting
> > > > > > Microsoft Customer Support Services (CSS) at:
>
> > > > > >http://msdn.microsoft.com/subscriptions/support/default.asp x.
>
> > > > > > ==================== =3D=
==================== =====3D=
====
>
> > > > > > This posting is provided "AS IS" with no warranties, and confers=
no rights.- Hide quoted text -
>
> > > > > - Show quoted text -- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -