Demystifying Schannel

First published on TechNet on Nov 13, 2017

Hello all! Nathan Penn here to help with some of those pesky security questions that have lingered for years. Recently I have been fielding several questions on "How do I make sure that I am only using the TLS 1.2 protocol?", "Can you disable 3DES and the legacy ciphers?", and the "I just got back from a security class and they talked about Diffie-Hellman, am I using it?".

The basics

Before we can start to answer any of that we have to build up some basics. An SSL session always begins with an exchange of messages called the SSL handshake. The handshake allows the server to authenticate itself to the client by using public-key techniques, and then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server. Secure Channel, or Schannel, is used to negotiate this security handshake between systems and applications. To perform this function, Schannel leverages the below set of security protocols, ciphers, hashing algorithms, and key exchanges that provide identity authentication and secure, private communication through encryption.

While all of the options above are available to the operating systems and Schannel, they are not offered up in an a-la carte manner. Each Windows operating system maintains a pre-defined list of combinations, referred to as the cipher suite, which are approved for communications. The list is prioritized, with the top/first cipher suite being the most preferred. Below is the default cipher suites included in Windows 10 v1703:

Dissecting the cipher suite, we can see the protocol, key exchange, cipher, and hashing algorithm as illustrated below. When the handshake is attempted, the client/server/application must negotiate until they find a common cipher suite. In addition to agreeing on a shared cipher suite, the protocol, key exchange, cipher, and hashing algorithm referenced by that cipher suite must be enabled and available for use, which they all are by default.

What is the system using?

Now that we have a basic understanding of a cipher suite and the components that make it up, how do you identify what the system is using? Enter Schannel logging which is written into the Windows System log. Schannel only logs basic information by default, however, we can turn the diagnostic logging up to include the detailed SSL handshake information by configuring the following registry key:

• HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
  • EventLogging (DWORD)
    • 1 (Basic)
    • 7 (Verbose)

Enabling verbose logging of Schannel has the potential to generate quite a few events pretty quickly, so use sparingly as you are testing/evaluating, and turn it back to basic when you are done. Taking a look into the System log we may want to filter for Event ID 36880 - SSL (client or server) Handshake Completed Successfully. Review of these entries will detail all the Schannel connections to/from the system. As we can see above the protocol used was TLS 1.2, and doing a quick Bing search on "CipherSuite: 0xC02F" reveals that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 was used for the connection. Now we know that for this particular connection we used the TLS 1.2 protocol, the AES 128-bit cipher, a SHA256 hash, and the ECDH key exchange algorithm. VOILA!

So, you want to manage it yourself...

Now that we know what Schannel is composed of, what it is used for, and can identify the cipher suites we are using, we all agree we should leave it alone and let the system manage it right? Hmmmm... Well then, let's get to breaking it (ahem... I mean tuning it). If we want to limit the cipher suite to only particular protocols, key exchanges, ciphers, or hashing algorithms we have two methods: Define a custom cipher suite priority, or disable the individual components. Before we get into it, I do want to call out one more time - Warning: Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

Method 1 - Defining a custom cipher suite

To define a custom cipher suite list, we will need to provide a comma separated list of the ciphers suites we want the system restricted to (remember the cipher suites must be in priority order). Additionally, there is a character limitation of 1023 characters, so choose your cipher suites wisely. That said, taking the predefined cipher suites in Windows 10 v1703 from the table above and converting it into a comma separated list would look like this:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_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_RC4_128_SHA,TLS_RSA_WITH_RC4_128_MD5,TLS_RSA_WITH_NULL_SHA256,TLS_RSA_WITH_NULL_SHA Now, if we were to take this same table and identify all cipher suites using a cipher prior to AES, and hashing algorithms weaker than SHA256, the table and comma separated list would now look like this:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_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_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 Once you have a comma separated list of cipher suites the systems should be restricted to, deployment and management can be easily accomplished via Group Policy. Identify, or create a new, group policy that applies to the systems that are to be updated. Edit that policy, and under Administrative Templates -> Network -> SSL Configuration Settings there is an "SSL Cipher Suite Order" setting (shown below). Enabling this setting and supply your comma separated list. Once the policy replicates and applies the systems will only use the updated cipher suites.

Method 2 - Disable the Individual Components

So maintaining a list of cipher suites isn't your thing, but you need to disable a particular component and disallow all the system configured cipher suites from using them. Unfortunately, there is no built-in group policy administrative template to help us this this time. The individual security protocols, ciphers, hashing algorithms, and key exchanges are all enabled on Windows by default, and to disable them requires a registry change. This change is done by adding the "Enabled" value to the associated component registry subpath that you want disabled and setting the value to "0" as illustrated below: While there is no built-in group policy administrative template to do this, I would still recommend leveraging a group policy and using the group policy preference (GPP) functionality to make these changes. Notice on the GPP example above has the "Remove this item when it is no longer applied" box selected. In the event that you would like to re-enable the component, removing the registry entry from the GPP will result in the key being deleted from the distant end and thereby re-enable the component. Below is a list of security protocols, ciphers, hashing algorithms, key exchanges, and their associated registry subpath. WARNING : Disabling all components in any category will result in Schannel not having a single cipher suite that it can use to negotiate the SSL handshake, (and yes, that is BAD)!!!

I hope all this helps clear things up and gives you an understanding of Schannel.

Additional Resources:

Supported cipher suites by Windows operating systems: https://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx Types of events that Schannel can produce: https://technet.microsoft.com/en-us/library/dn786445(v=ws.11).aspx Schannel SSP registry entries: https://technet.microsoft.com/en-us/library/dn786418(v=ws.11).aspx