I have been on a little bit of a security kick lately with my time at work thwarting SQL injection attempts, securing web servers, firewall administration and so much more and have been doing some pretty repetitive tasks so I thought I’d put them up here to help me remember how to do these very important tasks.
This piece is on restricting weak ciphers within your SSL certificates. Nessus and some other security auditing tools will detect this one with ease so there’s really no good excuse not to lock it down. Basically what we are going to do is remove the ability for web clients (IE, Firefox, Safari, Opera, etc) connect to the web server with anything but 128 bit or greater SSL encryption. This just sounds like a good deal anyway if you as me.
An example of a weak cipher is like I mentioned above, anything less that 128 bit encryption. There are about a dozen methods of encryption from SSL_RSA_EXPORT1024_WITH_RC4_56_SHA to SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5. Yes I know that sounds cryptic and it really is (pun intended). So what we need to do is scan the host first. You can use Tenable Nessus or your choice of scanning utility but we want to see what it comes up with. Chances are if you were diligent during the setup of the server, you may not have to do this but if your the other 95% out there, then you will need to do the following.
Open "regedit" and find the key
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers.
This will have a number of other subkeys below it. Next we will want to disable anything that has a number less than 128 in it. I.E. RC2 40/128 we will disable but RC2 128/128 we will not. Clear as mud? To disable the cipher click on the subkey that you want to disable and create a new DWORD value named Enabled. In the value data keep it 0 in Hex. This will disable the cipher from being able to run. You could also create a registry import like the following.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]
“Enabled”=dword:00000000
I would do this for RC2 40/128. RC4 40/128 and RC4 56/128. I feel better already. Hopefully you will too after you get this done on your website.
NOTE: This may break some clients/servers/applications so I take no responsibility for YOUR actions. 
#1 by Daniel Craig on June 23rd, 2008
Hello, I was looking around for a while searching for cipher locks and I happened upon this site and your post regarding / IIS SSL – Restrict Weak Ciphers | Braindump, I will definitely this to my cipher locks bookmarks!
#2 by Matt on October 13th, 2008
Great post. Along the same lines, admins should also look into disabling SSL 2.0, forcing users to connect w/ 3.0 or TLS 1.0.
#3 by clamasters on October 13th, 2008
@Matt Yes, I would 100% agree. Thank you.
#4 by James on January 15th, 2009
Many thanks… has helped me out with the error I was getting with SecurityMetrics PCI scan
#5 by Joey on January 19th, 2009
James – I was getting dinged by Security Metrics too. Hopefully, this will fix it without fixing my application.
#6 by Pav on January 20th, 2009
James, Joey – did it sort out Security Metrics for you. I’m still having problems with the ciphers. Let me know if you got it right.
#7 by Rick on January 22nd, 2009
Everyone’s one a PCI compliance kick…this: http://support.microsoft.com/kb/245030/en-us
tells how to only support SSL 3.0 or TLS 1.0 and not SSL 2.0
in a nutshell:
regedit to HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
then set the below to dword “Enabled”, value 0×0
\PCT 1.0\Client
\PCT 1.0\Server
\SSL 2.0\Client
\SSL 2.0\Server
#8 by Calazan on January 27th, 2009
Thanks! We passed the SecurityMetrics PCI scan by following your instructions.
Pav, for us we disabled the following:
DES 56/56
RC2 40/128
RC4 40/128
RC4 56/128.
And like the others said, SSL 2.0 support should also be disabled.
#9 by Marty on February 26th, 2009
Mahalo Nui Loa (Thank you very much in Hawaiian)
Your solution worked great!!! Really appreciate you publishing it.
#10 by Yong on March 30th, 2009
Any of this alteration affect your application?
#11 by clamasters on March 30th, 2009
Your mileage may vary. I have run this on 30 plus servers with zero issues but usually depending on the OS/Browser version of the client viewing the site/application, you may experience issues.
#12 by John on April 27th, 2009
Hello,
I am having the same problems with these ciphers and security metrics. I have disabled everything lower than 128 and I am still not passing the scan. Does anyone know if security metrics scans every server and workstation behind our Public IP or is it just the server that is port forwarded? I have been working on this for almost a month now and the security metrics tech support is of no help at ALL (what a joke), they do not even know what their tests scans!! Any help would be greatly appreciated.
Thanks!
#13 by Steve on May 21st, 2009
Hello
In reply to John
It does scan any and all servers behind the public ip… Assuming that this is a netscaler / load balancer for multiple web servers. The Virtual IP assigned represents all of the backend physical ips associated to the individual web sites. Best bet is to determine the physical ips associated to the Virtual IP that is throwing a positive from the scan. When that is done you’ll need to find the actual servers that these reside on. Apply these patches as directed above to those servers. Make sure you capture / back up the existing entries in the registry as I have seen this cause client issues with non IE browsers.
Good Luck!
Steve