In a post Heartbleed world, implementation of SSL is being scrutinized like never before (at least in my short years of experience in information security). Even though Microsoft/IIS implementations were hardly, if at all, affected by Heartbleed, they do often suffer from other common SSL vulnerabilities. This is particularly true of Microsoft Server 2003 R2 / IIS 6.5 and older setups.
Back in the olden days (you know, like 5 – 10 years ago…) before massive Chinese super-computers, NSA spying programs, and 30-core processors, a 48-Bit SSL cipher may have been considered sufficient as the length of time it would take to brute-force decrypt collected data was significant on the hardware of the day. No so much anymore.
Fast forward to today, many environments still have aging servers sitting around from a bygone era whose weak implementation of SSL pose a security risk. It is time to turn off archaic SSL ciphers on these old boxes and strengthen your connection security.
So… before you read any further, you need to check a few things to find out if this article is relevant to you.
First, do you host any websites in IIS that use SSL? (i.e. do they have “HTTPS” preceding the URL?) If so, pick out a random handful of those sites and go over to:
Run them through the online analysis. I recommend you click the option “Do not show the results on the boards.” If any of them come back with a score worse than a “B”, part of the reason is most likely due to the fact that they are allowing the use of “weak ciphers.”
How do we fix this and get up to at least a “B” grade?
We simply need to disable the usage of all older cipher suites. The concept is simple, but implementation in Windows Server is a bit of a pain. The reason being that it involves modifying the server’s registry and doing a system reboot.
Luckily you are reading this article though and I am going to attempt to lighten your burden at least a bit…
“.reg” files can be executed on any windows machine to quickly make changes to the registry. Rather than make you hunt around online to find the relevant Microsoft articles and other blogger commentary so you can piece things together (like I did about a year ago) I am just going to provide you with the registry files.
Making a bad registry edit can have all kinds of dire consequences. So please examine and test my file before you just go along blithely implementing registry changes on your production servers. I would also STRONGLY advise you to make a backup of your registry on each server before proceeding. Okay… end disclaimer…
You can download the registry file (it is zipped, decompress first, then execute) here:
UPDATE 06.15.2014 – After running an SSL Labs test on a site running on Server 2008 R2 I was surprised I was still getting a “B” grade. Apparently Server 2008/2008R2 does support the latest and greatest in SSL security but Microsoft moronically left them off by default. IF you are running on a server 2008 or 2008 R2 machine, you additionally will want THIS registry file: SSL-Secure-Settings-Server2008-2008R2.zip
In addition to editing the registry, you need to also flip a switch on each web application inside of IIS. Here is a graphic showing where to do that (Click to Enlarge… I apologize for the awful quality…):
Once the server registry changes have been made and the application setting has been ticked for each site in IIS, reboot the server and then test the site in a few different browsers to make sure nothing adverse has occurred. Older browsers, think IE8 and older, may have trouble accessing sites with the new changes. If your environment is stuck with some legacy browser, take this into consideration and test, test, and then test some more.