This article is contributed. See the original author and article here.
More Speaking in Ciphers and other Enigmatic Tongues with a focus on SCHANNEL hardening.
Hi! Jim Tierney here again to talk to you about Cryptographic Algorithms, SCHANNEL and other bits of crypto excitement. I have elucidated at length on this topic in this post which had been updated a few years back to the aptly titled, Speaking in Ciphers and other Enigmatic tongues…update!
I am creating this brand-new piece of content in this crypto space to further discuss different Microsoft supported methods that can be used to disable weak cipher suites and protocols.
The scenario we are addressing is that your company is doing a vulnerability and compliance assessment, and they just ran a scanning tool against all your Windows Servers. The software reports back that you have weak ciphers enabled, highlighted in RED and including a link to the following Microsoft documentation –
KB245030 How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll:
http://support.microsoft.com/kb/245030/en-us
You immediately open a case with Microsoft asking…. What can I do? What can I do?
There are two Microsoft supported methods of configuring cipher suites:
Via GP: https://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx
Via cmdlets: https://technet.microsoft.com/en-us/library/dn296632.aspx
How to limit the Cipher Suites that Windows will support
The Default location and ordering of Cipher Suites is located here:
| HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCryptographyConfigurationLocalSSL010002 |
NOTE: We strongly suggest NOT modifying the real registry location. Instead, we recommend leveraging the Group Policy setting below to manage the list of ciphers supported in the Operating System. If the Microsoft development team supports a new cipher, they could end up putting back ciphers you removed from this default location if you do this.
Configuring the Group Policy for Cipher suite ordering/content will overrule what is listed in this default location.
Here is the location of the Cipher Suite ordering group policy:
Computer ConfigurationAdministrative TemplatesNetworkSSL Configuration SettingsSSL Cipher Suite Order
Remember, when configuring the Cipher suite order policy, If the 1023 size is passed, Cipher suites will be truncated because the list exceeds the 1023-character limitation for the
*In addition, Windows Server 2016 and newer do not require the _PXXX suffixes, so the list of cipher suites is a lot shorter. Please note that Win10/2016 and above solves this problem in 2 ways:
- Elliptical Curve (EC) suffixes (also known as the _P values) are no longer part of the cipher suite names, therefore there is no more Cartesian explosion of cipher suite names (e. g. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384, …)
In Windows 10, curves are prioritized separately from cipher suites, which means the cipher suite list in the GP Editor is much shorter.
NOTE: These EC suffixes ARE required for Windows Server 2012 operating systems to limit the ciphers on the OS. However, Windows 10/2016 OS DOES NOT support these cipher names. So, if you still need to support Windows Server 2012 (you have my sympathy) then you will need to have a GPO for this OS specifically, and then we would also recommend that the GPO be configured with a WMI Filter for the OS version.
Create WMI Filters for the GPO | Microsoft Learn
- PowerShell cmdlets are provided for cipher suites enumeration/enabling/disabling/prioritization as indicated earlier: https://learn.microsoft.com/en-us/powershell/module/tls/?view=windowsserver2022-ps
Specifically for Windows PowerShell, the article below mentions how to update PowerShell scripts or the related registry settings to ensure 1.2 is used:
When the SSL Cipher Suite Order group policy is modified and applied successfully it modifies the following location in the registry:
| HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftCryptographyConfigurationSSL010002 |
Also remember, you should be eliminating weak ciphers from the list, not adding them to accommodate older operating systems.
Please take some time and review my previous blog – https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/speaking-in-ciphers-and-other-enigmatic-tongues-8230-update/ba-p/400362
And the following information as well – Protocols in TLS/SSL (Schannel SSP) – Win32 apps | Microsoft Docs
Words of Wisdom
Restricting supported TLS / SSL Protocols that are used.
If you have been using an old moldy script to configure SCHANNEL content on your Windows servers, you must seriously consider updating or rethinking this method and figure out the SCHANNEL protocols you want to disable on ALL these servers and configure ONLY WHAT YOU WANT DISABLED. TLS 1.2 is ENABLED by default in EVERY OS starting with WINDOWS 2012. YOU DO NOT NEED TO CREATE A REGISTRY SETTING FOR TLS 1.2
Enforcing the use of TLS 1.2 will require DISABLING any other protocol (i.e., TLS 1.0 and 1.1). Disabling SCHANNEL protocols and cipher suites can affect interoperability. Especially connectivity to applications, services and servers that are not current versions of their product.
What Ciphers should I leave enabled?
My advice regarding ciphers is to stick with the default cipher suites for their Windows version. These ciphers are carefully chosen and prioritized to provide a balance of interoperability, performance, and security. If there are specific security requirements, then a change to the list of the cipher suites and their priorities is needed. Some applications (third party, or Microsoft) may still need lesser TLS versions, so testing any SCHANNEL registry modifications is necessary.
Applications that might need older protocol versions.
.NET-based applications.
One glaringly apparent example of this is .NET.
Any .NET application written before 4.7 WILL have problems using TLS 1.2. By default, older versions of .NET prefer TLS 1.0 ONLY. See the following – https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls#configure-security-via-the-windows-registry
Example of the settings in the article above –
[HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoft.NETFrameworkv2.0.50727] [HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoft.NETFrameworkv4.0.30319] [HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv2.0.50727] [HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319] |
WinHTTP based applications.
WINHTTP – Typically this is services or applications that run as background services, and usually run as SYSTEM or NetworkService accounts.
https://learn.microsoft.com/en-us/windows-server/networking/configure-secure-protocol-options-winhttp?tabs=x86
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsWinHttp DefaultSecureProtocols = (DWORD): 0xAA0
HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionInternet SettingsWinHttp DefaultSecureProtocols = (DWORD): 0xAA0 |
WinINET based applications.
WinINET – Typically this is a user base application like any Office application that runs as the user account logged onto the system. They are going to be applications that run with an interactive desktop. It would be Internet Explorer, Or Edge running in IE (Internet Explorer) Mode. It DOES not include Edge/Chromium browsers, however.
KB5017811—Manage Transport Layer Security (TLS) 1.0 and 1.1 after default behavior change on September 20, 2022
https://support.microsoft.com/en-us/topic/kb5017811-manage-transport-layer-security-tls-1-0-and-1-1-after-default-behavior-change-on-september-20-2022-e95b1b47-9c7c-4d64-9baf-610604a64c3e
Group Policy: HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsCurrentVersionInternet Settings SecureProtocols = (DWORD): 0xAA0 HKEY_CURRENT_USERSOFTWAREPoliciesMicrosoftWindowsCurrentVersionInternet Settings SecureProtocols = (DWORD): 0xAA0
Registry: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet Settings SecureProtocols = (DWORD): 0xAA0 HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionInternet Settings SecureProtocols = (DWORD): 0xAA0 |
Modifying Signature/Hashing Algorithms
If you are still with me and have been poking around in the registry (on a test computer), you may have noticed the following location and would like some information regarding –
HKLMSYSTEMCurrentControlSetControlCryptographyConfigurationLocalSSL0010003 |
The value content of this location only affects TLS 1.2
Operating systems prior to Windows 2008 SP2 standard do not support this value item.
The data in the Functions value refer to the signature/hash combinations that are supported on TLS 1.2 certificate chains (excluding the root) as well as the signature/hash combinations that can be used when signing TLS 1.2 messages such as the ServerKeyExchange message and the CertificateVerify message.
The value in the (Default) location, NCRYPT_SCHANNEL_SIGNATURE_INTERFACE tells the server which signatures it can use to sign the ServerKeyExchange message and which signatures are allowed when verifying the server certificate chain.
These settings have nothing to do with disabling weak protocols or ciphers and should not be modified EVER!
The same hold true for this location as well –
| HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCryptographyConfigurationLocalDefault |
Reference –
I Just want the SCHANNEL Registry values to implement please.
If you are looking for just a quick list of SCHANNEL registry values to implement to help you pass a Security Scan/Audit here is an incredibly good list of values to implement to make sure the OS is not vulnerable to these older exploits.
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersDES 56 Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersNULL Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 40/128 Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 56/128 Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 128/128 Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 128/128 Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 40/128 Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 56/128 Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 64/128 Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168 Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168 Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELHashesMD5 Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELHashesSHA Enabled = (DWORD): 0xFFFFFFFF
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsMulti-Protocol Unified HelloServer Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersSchannelProtocolsMulti-Protocol Unified HelloClient Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersSchannelProtocolsPCT 1.0Client Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersSchannelProtocolsPCT 1.0Server Enabled = (DWORD): 0x0
KEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Client Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Server Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Client Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Client Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Server Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS1.1Client Enabled = (DWORD): 0x0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Server Enabled = (DWORD): 0x0
HKLMSystemCurrentControlSetControlLSASecurityProvidersSchannelProtocolsTLS 1.2Client DisabledByEnabled = (DWORD): 0x0 Enabled = (DWORD): 0x1
HKLMSystemCurrentControlSetControlLSASecurityProvidersSchannelProtocolsTLS 1.2Server DisabledByEnabled = (DWORD): 0x0 Enabled = (DWORD): 0x1
HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoft.NETFrameworkv2.0.50727 SystemDefaultTlsVersions = (DWORD): 0x1
HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoft.NETFrameworkv4.0.30319 SystemDefaultTlsVersions = (DWORD): 0x1
HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv2.0.50727 SystemDefaultTlsVersions = (DWORD): 0x1
HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319 SystemDefaultTlsVersions = (DWORD): 0x1
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsWinHttp DefaultSecureProtocols = (DWORD): 0x1
HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionInternet SettingsWinHttp DefaultSecureProtocols = (DWORD): 0x1 |
Vulnerabilities:
RC4 based Cipher Suites
SCHANNEL – RC4/Sweet32 Vulnerability information
These two updates are specific to RC4 based information here –
https://nvd.nist.gov/vuln/detail/CVE-2013-2566
https://nvd.nist.gov/vuln/detail/CVE-2015-2808
RC4 ciphers are NO LONGER SUPPORTED
See the following – Features that are removed or deprecated in Windows 10 Fall Creators Update
TLS RC4 Ciphers to be disabled by default. For more information, see the following Windows IT Center topic:
TLS (Schannel SSP) changes in Windows 10 and Windows Server 2016 –
DisabledByDefault change for the following cipher suites:
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (RFC 5246) in Windows 10, version 1703
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (RFC 5246) in Windows 10, version 1703
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA (RFC 5246) in Windows 10, version 1703
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA (RFC 5246) in Windows 10, version 1703
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (RFC 5246) in Windows 10, version 1703
- TLS_RSA_WITH_RC4_128_SHA in Windows 10, version 1709
- TLS_RSA_WITH_RC4_128_MD5 in Windows 10, version 1709
Once again please refer to the previous blog I wrote that explains SCHANNEL and Cipher Suite changes and what is and is not supported in Windows operating systems – https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/speaking-in-ciphers-and-other-enigmatic-tongues-8230-update/ba-p/400362
You should use this as a guide for modifying the SCHANNEL protocols, list of default ciphers, and removing the weaker ones completely. It should be a favorite in your browser settings and currently be open in the tab right next to the one you are using to read this article 
Regarding 3DES:
Sweet32 is a cryptographic attack against short block size (64-bit block) ciphers.
Vulnerability scanners will trigger this if a 3DES cipher suite is present. In Windows server, 3DES cannot be used as the only cipher but it is acceptable as an optional cipher suite for backward compatibility.
This is the minimum cipher in the negotiation list, so it is used only as a last resort.
TLS_RSA_WITH_3DES_EDE_CBC_SHA must not be offered on its own as it is considered inferior to the other cipher suites but should be offered for FIPS (Federal Information Processing Standards) constrained clients that do not have AES-based cipher suites available.
Microsoft also mitigates usage of this cipher by removing 3DES from available ciphers in the FalseStart list which prevents MiTM (Machine in the Middle) attack forcing encryption downgrade.
https://technet.microsoft.com/library/security/3155527.aspx
This mitigation is also listed on the website https://sweet32.info/
Vulnerability scanners should not be simply searching for registry keys indicating something is disabled (3DES). They should be reporting on configured Cipher Suites if they include 3DES.
Lucky Thirteen vulnerability mitigation
Disabling TLS 1.0 entirely.
The removal of all cipher block chaining (CBC) ciphers. EXAMPLE – TLS_RSA_WITH_AES_256_CBC_SHA256
There are a couple of CBC ciphers that are still supported in Windows 10
See the following – TLS Cipher Suites in Windows 10 v1903, v1909, and v2004 – Win32 apps | Microsoft Docs
3rd (non-Microsoft) party TLS implementations
I made all the changes to the SChannel registry values, and even rebooted my server but some endpoints are still showing as vulnerable when I run my security scanning software again. Why did this not fix all my problems?
Keep in mind that Microsoft is not the only TLS implementation on the scene. Java and OpenSSL are just a couple of third-party SSL/TLS implementations that do not leverage the Microsoft SCHANNEL Security Support Provider Interface (SSPI) at all. If you have implemented the above registry values and rebooted the server and the scanning tool is still showing a vulnerability it is time to start thinking that this may not be an application that is using Microsoft implementation of SSL/TLS. To investigate this:
- The first thing to do is look at your scan report and determine what network port or ports the scanning tool is indicating are still vulnerable.
- On the computer being reported as vulnerable open an elevated command prompt and type: NetStat –ANOB > %ComputerName%_Netstat.txt.
- Once it is done, then you can open the text file created, and search for the port determined from step 1.
- It will give you the process name that is listening on that port. If it is Java.exe/Javaw.exe or OpenSSL.exe then this is not something Microsoft support is going to be able to help with. We will redirect you to the vendor of your 3rd party application.
If this is the case, you will need to contact those vendors to get those configured applications configured properly.
Enabling verbose SCHANNEL logging may also help you determine what third party SCHANNEL applications are installed on your servers by configuring verbose logging. Verbose logging will show successful and failing connections providing the protocol and ciphers being used in addition to the computer from which the connection is coming from:
HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL EventLogging (DWORD) 1 (Basic) 7 (Verbose) |
You should also be aware that Intune policy can also be leveraged to manage cipher suites as well. These settings may interfere with your SCHANNEL policies and configurations.
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCryptographyMDMPoliciesSSL CipherSuites REG_SZ |
I trust you have found this content both illuminating and enjoyable in your efforts to secure your SCHANNEL environment without sacrificing the necessary functionality. If you should you encounter any hurdles along the way, please don’t hesitate to reach out to us for assistance. We’re here to support your continued success with Windows. Happy Hunting!
Jim “How I learned to stop worrying and ♥ Crypto” Tierney
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments