Cipher Suites on Windows Server 2016/2019

“Static Key Ciphers” are used on Windows Server 2016/2019 for backward compatibility with legacy applications. It existing on Windows operating system by default. Hackers can decrypt the traffic if the weak cipher suites are being used. Hence how to secure the traffic is important for Windows security.

In short, certain communication security protocols and cipher suites should be disabled on Windows Server 2016/2019.

What’s Cipher?

Cipher is the algorithm of translation between plaintext and ciphertext. There are two algorithm categories: The symmetric key algorithm and the asymmetric key algorithm. Symmetric key algorithms use one key for encryption and decryption. Asymmetric key algorithms use different keys for encryption and decryption.

The popular ciphers are DES, AES, RSA, SHA…etc. However, some of them are out-of-date. And some maybe not in compliance with certain information security standards.

What’s the Cipher Suite?

A cipher suite is a set of ciphers and security protocols. A server encrypts data with a cipher suite. And a client decrypts data with the same cipher suite.

Naming Convention of Ciphers

Different Windows Server versions support different cipher suites. Following is the default cipher suite list for TLS protocol on Windows Server 2016/2019. As you can see, Windows Server 2019 supports few advanced cipher suites in addition.

Cipher Suites have an order on Windows. It always picks up the best cipher suite. “The best” means it must match two criteria:

  1. At least one cipher suite in the order must be supported by the application.
  2. The chosen cipher suite is the top one in the supported list.

If Windows cannot find a suitable cipher suite, then the communication is failed. As a result, you will see error messages in Windows Event Log (Similar to the event log samples below).

Windows Server 2016 Windows Server 2019
N/A TLS_AES_128_GCM_SHA256
N/A TLS_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA N/A
TLS_DHE_DSS_WITH_AES_128_CBC_SHA N/A
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 N/A
TLS_DHE_DSS_WITH_AES_256_CBC_SHA N/A
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 N/A
TLS_DHE_RSA_WITH_AES_128_CBC_SHA N/A
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256*
TLS_DHE_RSA_WITH_AES_256_CBC_SHA N/A
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384*
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256*
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384*
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256*
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384*
TLS_PSK_WITH_AES_128_CBC_SHA256 TLS_PSK_WITH_AES_128_CBC_SHA256
TLS_PSK_WITH_AES_128_GCM_SHA256 TLS_PSK_WITH_AES_128_GCM_SHA256
TLS_PSK_WITH_AES_256_CBC_SHA384 TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_AES_256_GCM_SHA384 TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_NULL_SHA256 TLS_PSK_WITH_NULL_SHA256
TLS_PSK_WITH_NULL_SHA384 TLS_PSK_WITH_NULL_SHA384
TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_NULL_SHA TLS_RSA_WITH_NULL_SHA
TLS_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_RC4_128_MD5 N/A
TLS_RSA_WITH_RC4_128_SHA N/A

Which Should Be Disabled?

Firstly we need to look into the communication security protocols. SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2 are popular protocols. They are enabled on Windows Server 2016/2019 by default. However, most of them are out-of-date due to certain vulnerabilities. For example, SSL 3.0 is killed by the POODLE attack. So the suggested protocol is TLS 1.2.

The protocols are controlled by registry keys. The registry location is HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.

There are two keys for each protocol: Client and Server. The Microsoft KB only introduced how to disable PCT 1.0 for Server. You need to do the same for the Client. The KB was written for the earlier Windows version. But it also applicable for Windows Server 2016/2019

Secondly, dealing with cipher suites. There are a lot of articles on the internet to talk about cipher suites. But no straight answer on what should be disabled and how. I think the easiest way is to compare your current cipher configuration with the blacklist of RFC 7540.

I compared Windows Server cipher suites with it. All cipher suites in the table above are on the blacklist except the green text. In other words, the green text cipher suites are safe for TLS 1.2.

If you follow the blacklist. As a result, there will be only 6 cipher suites for Windows Server 2016 and 8 for Windows Server 2019. Most importantly. It may cause a lot of problems since the cipher suites may not be supported by the majority of 3rd party applications.

So, to balance security and compatibility. I think it may be reasonable to disable the out-of-date cipher suites only. After research. I think the cipher suites with red text in the table can be disabled on Windows Server 2016/2019.

You can get the current cipher suite configuration list with PowerShell:

(Get-TlsCipherSuite).Name

What’re the Impacts to Disable Cipher?

Because the cipher suite must be supported by application and Windows both. Therefore, there are two impacts to disable cipher suites on Windows Server 2016/2019. Firstly, it’s the internal impact. It means the native application may throw out errors if it doesn’t support TLS 1.2. For example, you may see the following error in Windows Event Logs after disabled SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 on a new provisioned Windows Server 2016/2019. The reason is TLS support for the .Net framework is not enabled.

Log Name: System
Source: Schannel
Date: 10/11/2020 1:1:1 PM
Event ID: 36871
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: test.zhengwu.org
Description:
A fatal error occurred while creating a TLS client credential. The internal error state is 10013.

Secondly, It may impact communication with external services. For example, the 3rd party software only supports the disabled cipher suites. You may see following log in Windows Event Log:

Log Name: System
Source: Schannel
Date: 10/11/2020 11:11:01 PM
Event ID: 36874
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: test.zhengwu.org
Description:
An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The TLS connection request has failed.

How to Disable Cipher Suites?

There are several ways to control cipher suites. GPO is the recommended way. Or you can edit registry keys. But it’s inflexible. For example, It takes time to change the registry to disable a single cipher suite.

Microsoft introduced the PowerShell TLS module since Windows Server 2016. It supports to control a single cipher suite. I think it’s a better way compared with other ways. Because you can re-enable a cipher suite easily if the application doesn’t work.

Following is the command to disable cipher suite.

Disable-TlsCipherSuite -Name <xxx>

References

CVE-2017-5754, CVE-2017-5753 and CVE-2017-5715 (Spectre and Meltdown)

You may know there are 3 vulnerabilities recently noticed by industry. Long story to short, kernel address space exposed to hackers when processors running user space code. It’s not only impact to Intel processors but also AMD and ARM. CVE-2017-5715 is a hardware issues that only apply certain firmware can fix the vulnerabilities. CVE-2017-5754 and CVE-2017-5753 need to apply OS patches to change how codes access kernel address space. Following are some useful links just for your reference.

CVE-2017-5753

CVE-2017-5715

CVE-2017-5754

VMware: https://www.vmware.com/security/advisories/VMSA-2018-0002.html (For CVE-2017-5753 and CVE-2017-5715. VMware has not published anything for CVE-2017-5754 yet.)

Microsoft: https://support.microsoft.com/en-gb/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution
https://support.microsoft.com/en-gb/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in

HPE: http://h22208.www2.hpe.com/eginfolib/securityalerts/SCAM/Side_Channel_Analysis_Method.html

Cisco: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180104-cpusidechannel