How to enforce TLS on Windows

Question

In Windows 2008 R2 and 2012, how do you enforce TLS-only and how do you demonstrate that posture?

I am in IP Compliance and have a strong background in practical system administration and support. I have however been too far away from windows administration and support for long enough that I don't know the answer to this question any longer and wouldn't know the 2012 analog anyway, and I do not have test systems available for me to poke around in.

So for PCI compliance, all versions of SSL have been deprecated and retired by NIST as strong encryption, which makes TLS the de facto replacement for SSL. Most implementations of SSL default to TLS anyway when possible, but I need to know how to enforce TLS-only.

I have been searching the google, but no matter how I seem to word the question, I get a cloud of "how to enable" type material which I am not at all interested in. In our unix environments it a simple matter (I am a unix head anyway) but how does one enforce TLS only on windows systems. For one, unfortunately I am the leading technical expert at my company whilst not in a technical role, and I'll have to prove this out to our Directory of Infrastructure that this needs to happen (if so), but additionally I must be able to prove our systems are compliant and need a configuration dump or output from a command that shows which ciphers and methods are available for connection attempts.

So, in windows 2008 R2 and 2012, how do you enforce TLS-only and how do you demonstrate that posture?

Answer 1

For Windows operating systems, Microsoft has multiple KB Articles and other references to address SSL/TLS configuration.

Microsoft KB Article 245030, How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll has practically everything you'll need to know. Currently, the KB Article covers operating systems ranging from NT 4 up to Server 2012. The specific operating systems and editions covered within that range appear unusually inconsistent, but this should probably be effective for all Microsoft operating systems within that timeline.

There is also a TechNet article, TLS/SSL Settings which is currently scoped to broadly apply for all editions of Windows from Vista to 8.1, and from Server 2008 to Server 2012. This largely duplicates the details from KB Article, but also includes some Group Policy information and other useful details.

The main thing to be aware of, from the above references, is that there are a number of Registry keys and values within HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL which govern what SSL/TLS cipher suites and protocols will be allowed. Usage and effects of each are generally pretty obvious, assuming that the keys and values actually exist (default installations may omit some). Refer to the KB and TechNet articles for more detail, or Google for information about "SCHANNEL" Registry entries.

However, the above is only effective for applications and services which rely on SCHANNEL for SSL/TLS security. Non-Microsoft programs very often come with their own SSL/TLS implementation which must be configured separately. This is especially true for any applications which provide a web interface that is not served via IIS. In some cases, you will not be able to configure these options yourself, or you may have to "hack" them in without vendor support, for a non-Microsoft program. You'll have to investigate the support options for each application on a case-by-case basis.

Also bear in mind that SSL/TLS is not only used for websites. E-mail, remote access protocols, directory services, and many other applications and services also rely on SSL/TLS for connection security.

For testing the configuration, you will need tools like Wireshark or Fiddler to inspect the SSL/TLS handshake. The handshake will contain information about what cipher suites and protocols are supported by the server and client. Automated vulnerability scanning tools like Nessus, and penetration testing toolkits like Kali Linux, also commonly have utilities to test this. However, they may not be configured out-of-the-box to target all of your specific SSL/TLS-dependant applications or services. Google for usage guides, or post separate questions on an appropriate StackExchange site, as needed.