Configuring secure cipher suites in Windows Server 2019 IIS
I normally deal with multiple problems with webservers running insecure cipher suites and what better way to provide guidance so that you can avoid the pitfalls of running insecure cipher suites over encrypted connections inside of IIS.
So here I am running IIS in a very common configuration where my website is encrypted with a SHA256 hashed certificate with a RSA 2048 bit key to encrypt communication to the web server. I’ve also invoked an administrator command prompt to prove I am running the Server 2019 build of Windows.
On the back end I will run an nmap script to the targeted server to enumerate supported SSL cipher suite configurations. Two things we will be looking at is the use of insecure encrypted protocols and legacy cipher suites that are unfortunately still enabled on Windows Server 2019. If you do a lot of PCI compliance than you should be familiar with the mandate that SSL and TLS 1.0 should no longer be used after June 30, 2016.
First we will disable TLS 1.0 on Windows Server 2019 through the registry editor in the following location:
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\
I will create a key called TLS 1.0 and subkeys for both client and server. Along with that I will create a 32bit dword value called “Enabled” and set it to 0 as shown in the screenshots below.
Next I will reboot the target server and re-run my nmap scan. Take note my webserver can no longer negotiate over TLS 1.0 since I have disabled through the registry.
Next comes the tricky part. This really depends on the web applications you run and the cipher suites they are designed to support. Most modern web applications should support the use of stict TLS 1.2 and SHA256 and above cipher suites. Anything that uses a SHA1 cipher suite will definitely be picked up when doing a modern vulnerability scan against web applications. SHA1 is a legacy cipher suite and should be disabled. So the issue is two fold. If we disabled SHA1, TLS 1.1 will become unusable because it does not support any cipher suites above SHA1 as shown above in my screenshot.
Lets disable TLS 1.1 in the registry first by going to: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\
Create Keys and subkeys for TLS 1.1 for client and server along with the dword value of enabled and set to 0. Screenshots are shown below.
Next I will reboot the web server again and run another nmap scan. As you can tell below TLS1.2 is the only supported security protocol with the following cipher suites:
Now lets eliminate the use of any SHA1 Cipher suites on this server. Before doing this you should know how your web application is negotiating over secure channels. Second…order matters! I will be assigning the following cipher suite order in the priority list below:
— — — — — — — — — — — — — —
Priority Order
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
Below is the reference documentation I used to make the determination on secure cipher suite order. Since I’ve eliminated TLS 1.0 and TLS 1.1 and my web application is working this should be a sound process to follow
Reference Documentation:
Next I will need to establish this cipher suite order in group policy. Open up gpedit.msc
Navigate to the following policy:
Computer Configuration\Administrative Templates\Network\SSL Configuration Settings
I’ve inserted the cipher suites in the following order in accordance with the referenced Microsoft Documentation.
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
This will be a good reminder to make sure there are no spaces in between your comma’s. I’ve made that mistake before and it will cause your server to go into a boot loop. So be very careful how you put your order in this policy. Once finished I will reboot my server and run another NMAP scan against it.
After the NMAP scan is complete I now have a webserver that is configured with strict TLS 1.2 communication using strong cryptographic cipher suites.
This work is very tedious and requires a good working knowledge of server applications. A good place to start is with a simple vulnerability scan. One of my favorites to use is nessus. It will report all protocols and TLS versions in use. Start with disabling TLS protocols such as TLS 1.0 first. Then look at cipher suites. Always deploy these types of fixes in test first before production and remember that your cipher suite order does matter.
