What is the difference between the DisabledByDefault and Enabled SSL/TLS registry keys on Microsoft Windows?

Microsoft provides best practices guidance for Transport Layer Security (TLS). This document describes registry keys that can enable or disable a specific protocol.

https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls#configuring-schannel-protocols-in-the-windows-registry

For example, to enable TLS 1.2, you can add the following registry keys.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:FFFFFFFF

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:FFFFFFFF

What is the difference between DisabledByDefault and Enabled? They seem redundant.

Solution

In the SCHANNEL_CRED structure that is passed to AcquireCredentialsHandle as part of setting up a secure channel, you can optionally manually select the protocols to support, in the grbitEnabledProtocols bitmask field.

Thus, Enabled governs what protocols you can enable here while DisabledByDefault specifies whether the protocol is enabled if you omit this field (i.e. leave it as 0).

The Managing SSL/TLS Protocols and Cipher Suites for AD FS | Microsoft Docs article recommends to set DisabledByDefault to 1 for disabled protocols, too, in addition to setting Enabled to 0. So it looks like DisabledByDefault is used unconditionally to autogenerate the value for this field if it's omitted.

The field's note says that it's not recommended for use in new code. So these two registry values are almost redundant:

For new development, applications should set grbitEnabledProtocols to zero and use the protocol versions enabled on the system by default.

This member is used only by the Microsoft Unified Security Protocol Provider security package.

The global system registry settings take precedence over this value. For example, if SSL3 is disabled in the registry, it cannot be enabled using this member.

It's unclear what happens if you try to use a non-enabled protocol. Judging by the last paragraph and a lack of any relevant AcquireCredentialsHandle error code for this case, my guess is it's probably ignored.