1

I have a system with custom cipher suites specified in this registry key HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002!Functions

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA
TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_AES_128_GCM_SHA256
TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_AES_128_CBC_SHA256
TLS_PSK_WITH_NULL_SHA384
TLS_PSK_WITH_NULL_SHA256

However, I can see from Wireshark traces that Windows sends only 17 cipher suites out of the list of 29. In particular, it doesn't send these two cipher suites accepted by the server:

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

enter image description here

Can someone tell me why this can happen?

2
  • 1
    There is no "Windows sends ...". There are application which do the sending. These applications might or might not use the Windows TLS stack (Chrome, Firefox and probably even Edge do not) and even applications which use it might have their own non-default settings. It is unclear which application you look at. Sep 20 at 11:29
  • @SteffenUllrich I can confirm that you are correct that Edge does not. It uses the Chromium TLS stack (BoringSSL) and not schannel.
    – Xander
    Sep 20 at 11:35
3

You start out with this custom list of suites:

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA
TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_AES_128_GCM_SHA256
TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_AES_128_CBC_SHA256
TLS_PSK_WITH_NULL_SHA384
TLS_PSK_WITH_NULL_SHA256

The ones in your Wireshark capture are as follows:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

This leaves these as the unsupported ones:

TLS_PSK_WITH_AES_256_GCM_SHA384
TLS_PSK_WITH_AES_128_GCM_SHA256
TLS_PSK_WITH_AES_256_CBC_SHA384
TLS_PSK_WITH_AES_128_CBC_SHA256
TLS_PSK_WITH_NULL_SHA384
TLS_PSK_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA
TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

PSK suites require a pre-shared key to be configured with the remote host, so those are automatically unsupported in this usage context. If you don't have a configured PSK, these suites cannot work, so there's no point sending them. In SChannel this is configured using the SCH_USE_PRESHAREDKEY_ONLY flag when the application sets up a connection.

NULL ciphers have no encryption. They are prohibited by policy in almost every client. In SChannel specifically, the SCH_USE_STRONG_CRYPTO flag prohibits the use of NULL ciphers, and this flag is enabled by default.

The TLS_AES_256_GCM_SHA384 and TLS_AES_128_GCM_SHA256 suites are TLS 1.3 suites. Notice that they only specify a cipher, mode, and handshake MAC, and they have no mention of RSA, ECDSA, DHE, or ECDHE. The long-term authenticity provider (e.g. RSA, ECDSA) and key-exchange (e.g. DHE, ECDHE, RSA) are separately agreed upon in TLS 1.3. These cipher suites will not be sent if your client doesn't support TLS 1.3. Windows does not support TLS 1.3 in SChannel until Windows Server 2022 for server SKUs or until Windows 11 for desktop SKUs, so configuring these cipher suites is not going to do anything on previous versions.

The TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 suites are an oddity. In Windows 10 v1903 and onwards, use of the TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 suite is prohibited by the SCH_USE_STRONG_CRYPTO flag. I could not find any official documentation as to why this change was made, or why TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 escaped a similar fate. However, I think I have a good guess.

The DHE suites utilise regular Diffie-Hellman, i.e. DH without elliptic curves. The SChannel implementation of DHE suites utilises a hard-coded DH key size of 1024 bits, which is now considered weak. When Microsoft patched MS14-066, a code execution bug in SChannel, it appears that they also disabled these two suites. Depending on which version of Windows you have, the DHE suites may or may not be available. As for why TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 is still documented as being allowed in SChannel with SCH_USE_STRONG_CRYPTO, it is likely that Microsoft considered the security level of 1024-bit DH and the security level of the AES-128-GCM bulk cipher plus SHA256 for the handshake MAC to be acceptably close to one another. However, when you jump up to AES-256-GCM and SHA384, the security levels are nowhere near close to that of 1024-bit DH, so you're getting a false sense of security.

1

I just had to resolve a similar issue, if you go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms on your system and there is a Diffie-Helman key, try removing it (after backing up the key) and rebooting. The presence of this key can disable the DHE key exchange which prevents the system from supporting the cipher suites with Diffie-Helman.

I also removed all of the entries under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers since they were old ciphers but I don't think these were the problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.