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.

<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=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 <smurf...@xxxxxxxxxxxxxx> 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 <smurf...@xxxxxxxxxxxxxx> 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\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

""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/ed5ae700-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/default.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.aspx.

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

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 -


.

Relevant Pages

  • RE: Active Sync OMA http/1.1 500 error
    ... > use Basic Authentication for these three VD, disable SSL Windows ... > Microsoft CSS Online Newsgroup Support ... > This newsgroup only focuses on SBS technical issues. ... > | But by disabling it my OWA stopped to work. ...
    (microsoft.public.windows.server.sbs)
  • SSL Certificate causes Internet Exporer error
    ... I also use SSL, ... I used SSL and enabled SmartNavigation on the Log inn ... You are right, disabling SSL also removes the problem, ... Internet Explorer. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • RE: Active Sync OMA http/1.1 500 error
    ... use Basic Authentication for these three VD, disable SSL Windows ... Microsoft CSS Online Newsgroup Support ... |> Please make sure Server ActiveSync is enabled globally in your Exchange ... | But by disabling it my OWA stopped to work. ...
    (microsoft.public.windows.server.sbs)
  • Re: Direct Push - Connects & Syncs, but Inbox remains empty
    ... articles, including rebuilding the vdirs, disabling the AV, and the ... I'm trying to get my new Treo 750 to sync over wireless ... I run the Exchange server from my own house, ... I tried connecting via SSL only to get a message about the ...
    (microsoft.public.exchange.admin)
  • Re: Disabling SSL 3 and/or TLS 1 in SBS 2003
    ... but couldn't find any information on disabling SSL3. ... Maybe I just need to know how to make SSL 3 user a higher cipher strength. ... Are they processing credit card info on their SBS server? ... reported that the server supports "the use of SSL ciphers that offer ...
    (microsoft.public.windows.server.sbs)