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?

JIMT05_3-1706909626667.png

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_MACHINESYSTEMCurrentControlSetControlCryptographyConfigurationLocalSSL 010002

NOTE: We strongly suggest NOT modifying the real registry location. Instead, we recommend leveraging the 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

JIMT05_4-1706909626673.png

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, 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:

  1. 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 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 2012 (you have my sympathy) then you will need to have a for this OS specifically, and then we would also recommend that the be configured with a WMI Filter for the OS version.

Create WMI Filters for the GPO | Microsoft Learn 

  1. 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:

https://learn.microsoft.com/en-us/security/engineering/solving-tls1-problem#update-windows-powershel…

When the Cipher Suite Order group policy is modified and applied successfully it modifies the following location in the registry:

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftCryptographyConfigurationSSL 010002

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…

And the following information as well – Protocols in TLS/SSL (Schannel SSP) – Win32 apps | Microsoft Docs 

Words of Wisdom

Restricting supported TLS / 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-th…

Example of the settings in the article above –

[HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoft.NETFrameworkv2.0.50727]
“SystemDefaultTlsVersions”=dword:00000001
“SchUseStrongCrypto”=dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoft.NETFrameworkv4.0.30319]
“SystemDefaultTlsVersions”=dword:00000001
“SchUseStrongCrypto”=dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv2.0.50727]
“SystemDefaultTlsVersions”=dword:00000001
“SchUseStrongCrypto”=dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319]
“SystemDefaultTlsVersions”=dword:00000001
“SchUseStrongCrypto”=dword:00000001

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-winhtt…   

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

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 –

HKLMSYSTEMCurrentControlSetControlCryptographyConfigurationLocalSSL 0010003

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!

JIMT05_5-1706909626677.jpeg

The same hold true for this location as well –

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCryptographyConfigurationLocalDefault

Reference –

https://learn.microsoft.com/en-us/windows/win32/seccng/cng-interface-identifiershttps://learn.micros…  

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
SchUseStrongCrypto = (DWORD): 0x1

HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoft.NETFrameworkv4.0.30319

SystemDefaultTlsVersions = (DWORD): 0x1
SchUseStrongCrypto = (DWORD): 0x1

HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv2.0.50727

SystemDefaultTlsVersions = (DWORD): 0x1
SchUseStrongCrypto = (DWORD): 0x1

HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319

SystemDefaultTlsVersions = (DWORD): 0x1
SchUseStrongCrypto = (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

https://support.microsoft.com/en-us/help/4034825/features-that-are-removed-or-deprecated-in-windows-…   

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 –

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-schannel-ssp-changes-in-windows-10-…  

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…

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 :cool:

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

  1. The first thing to do is look at your scan report and determine what port or ports the scanning tool is indicating are still vulnerable.
  2. On the computer being reported as vulnerable open an elevated command prompt and type:  NetStat –ANOB > %ComputerName%_Netstat.txt.
  3. Once it is done, then you can open the text file created, and search for the port determined from step 1.
  4. 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

 

This article was originally published by Microsoft's Directory Services Team. You can find the original article here.