Hardening SSL & TLS connections on Windows Server 2008 R2 & 2012 R2

SSL-Scan-Main

Hardening your SSL/TLS connections is a pretty common thing to do on any Windows Server running IIS and web applications that utilize HTTPS, especially if they require some sort of compliance. It is generally a good idea to do this on all of your servers though, to ensure your secure connections really are secure.

On Windows, all of the SSL/TLS connections are going to be handled by the SChannel.dll, whereas on Linux these items would typically be handled by something like OpenSSL. You may also notice that OpenSSL is a bit quicker to adapt to more stout security standards than Windows, unfortunately in this situation we are at the mercy of Microsoft to offer patches for any issues that may arise. So keep in mind that there may be flags when running scans against your server that you may not be able to resolve on Windows at this time (ie 2048 bit DHE groups and TLS_FALLBACK_SCSV). The same thing goes with satisfying higher end cipher suite support requirements.

Also, you should be using a SSL certificate signed with SHA2/SHA256.

Where and how to make changes to the SChannel.dll:

Schannel-registry

All of the configuration changes to the Schannel.dll will stored in the registry. You can find these items at the following path in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\

While you can make changes directly against the registry, I highly recommend using IISCrypto from Nartac to make the changes to ensure the process goes a smooth as possible.

You can use the following command to back up the SChannel registry settings prior to making the changes, should you need to restore it:

Reg export HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ SChannel-Backup.reg

Warnings and Gotchas:

There are a few things to look out for when making changes to the SChannel.dll on Windows and you will want to be sure to test each of the following items if they apply to your environment:

  1. MS SQL requires TLS 1.0 to be enabled on the server it is running on, unless you have made the changes mentioned here:
    Disabling TLS 1.0 with MS SQL 2012 & 2014.

    TLDR – If the proper CU is not installed for SQL, the services won’t start and if .Net 4.6 is not installed, you won’t be able to connect via SSMS after TLS 1.0 has been disabled.

  2. RDP will likely break when disabling TLS 1.0 and there is no support for TLS 1.1/1.2. You can try forcing RDP Security Layer under the RDP-TCP settings as an alternative, but if you are using SSL Certificates like commonly done when deploying RDWeb, you will need TLS 1.0 enabled.
  3. Older clients may not be able to connect if they do not support the newer SSL/TLS technologies and you disable the older ones. Out of the box Windows Server is configured to be relatively compatible with older clients, which in turn makes it less secure. You can find a complete browser compatibility list here:
    https://en.wikipedia.org/wiki/Template:TLS/SSL_support_history_of_web_browsers
  4. Qualys will ding you for supporting 1024 bit DHE groups, and will recommend DHE key exchanges be increased to 2048 bit or disabled, but 1024 is the limit on Windows at this time. Meanwhile Google Chrome prefers DHE key exchanges be enabled so the TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher can be used to satisfy the “Obsolete cryptography warning”. Typically I will go with Qualys’s recommendation on this one.
  5. Be sure to thoroughly test your applications after making any changes, mainly looking for connection failures over HTTPS.

My go to Security vs. Compatibility balanced configuration for Server 2008 R2 and up:

This configuration should be compatible with most modern software while providing a relatively robust SSL/TLS configuration and scoring you a decently high score on Qualys’s SSL Labs tester at the same time.

IISCrypto-Arrows

  1. Use IISCrypto to apply the “Best Practices” Template
  2. Disable TLS 1.0 (Assuming SQL is not on the server or these updates have been applied and RDS/RDWeb is not deployed)
  3. Disable MD5 under Hashes enabled
  4. Disable Diffie-Hellman under Key Exchanges Enabled
  5. Apply and reboot
  6. Test your site with Qualys’s SSL Labs tester

Note: As of Oct. 2015, you should be able to score the following with Windows Server 2012+ (2008 R2 should be similar if not the same) on the Qualys SSL Scanner:

SSL-Scan-Main

Related Links:

Comments are closed.