David thanks for your input on this. I appreciate your time, and what you
are saying.
by default from Windows 2000 Server to Windows 2003 Server. Again, if SSL
connect. The idea I guess woudl be to harden the Default install - or a
I get what you are saying and true there is no perfect world. But lets face
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
I appreciate your input...
"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...@news.postalias> 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...@news.postalias> 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
> >