NOTE: This post has been completely revised and updated since its initial release in 2011. Please see the newer version of this post here:
Hi! Jim here again to talk to you about Cryptographic Algorithms, SChannel and other bits of wonderment. So, your company purchases this new super awesome vulnerability and compliance management software suite, and they just ran a scan on your Windows Server 2008 domain controllers and lo! The software reports back that you have weak ciphers enabled, highlighted in RED, flashing, with that "you have failed" font, and including a link to the following Microsoft documentation –
KB245030 How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll:
The report may look similar to this:
The Secure Socket Layer (SSL) protocol allows for secure communication between a client and a server.
There are known flaws in the SSLv2 protocol. A man-in-the-middle attacker can force the communication to a less secure level and then attempt to break the weak encryption. The attacker can also truncate encrypted messages.
Upon hearing this information, you fire up your browser and read the aforementioned KB 245030 top to bottom and RDP into your DC’s and begin checking the locations specified by the article. Much to your dismay you notice the locations specified in the article are not correct concerning your Windows 2008 DC’s. On your 2008 DC’s you see the following at this registry location:
"Darn you Microsoft documentation!!!!!!" you scream aloud as you shake your fist in the general direction of Redmond, WA….
This is how it looks on a Windows 2003 Server:
The registry key’s and their content in Windows Server 2008, Windows 7 and Windows Server 2008 R2 look different from Windows Server 2003 and prior. The referenced article isn't accurate for Windows Server 2008. I am working on getting this corrected.
Here is the registry location on Windows7 – 20008 R2 and its default contents:
· The Ciphers key should contain no values or subkeys
· The CipherSuites key should contain no values or subkeys
· The Hashes key should contain no values or subkeys
· The KeyExchangeAlgorithms key should contain no values or subkeys
· The Protocols key should contain the following sub-keys and value:
DisabledByDefault REG_DWORD 0x00000001 (value)
· SSL 2.0
· SSL 3.0
· TLS 1.0
· TLS 1.1
· TLS 1.2
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0][HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Client]
This is how it looks in the registry after they have been created:
Client SSL 2.0 is disabled by default on Windows Server 2008, 2008 R2 and Windows 7.
This means the computer will not use SSL 2.0 to initiate a Client Hello.
So it looks like this in the registry:
Just like Ciphers and KeyExchangeAlgorithms, Protocols can be enabled or disabled.
To disable other protocols, select which side of the conversation you want to disable the protocol, and add the "Enabled"=dword:00000000 value. The example below disables the SSL 2.0 for the server in addition to the SSL 2.0 for the client.
"DisabledByDefault"=dword:00000001 <Default client disabled as I said earlier>
"Enabled"=dword:00000000 <Disables SSL 2.0 server-side>
After this, you will need to reboot the server. You probably do not want to disable TLS settings. I just added them here for a visual reference.
So why would you go through all this trouble to disable protocols and such, anyway? Well, there may be a regulatory requirement that your company's web servers should only support Federal Information Processing Standards (FIPS) 140-1/2 certified cryptographic algorithms and protocols. Currently, TLS is the only protocol that satisfies such a requirement. Luckily, enforcing this compliant behavior does not require you to manually modify registry settings as described above. You can enforce FIPS compliance via group policy as explained by the following:
The effects of enabling the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting in Windows XP and in later versions of Windows – http://support.microsoft.com/kb/811833
The 811833 article talks specifically about the group policy setting below which by default is NOT defined –
Computer Configuration\ Windows Settings \Security Settings \Local Policies\ Security Options
The policy above when applied will modify the following registry locations and their value content.
Be advised that this FipsAlgorithmPolicy information is stored in different ways as well –
Windows 7/2008 –
"Enabled"=dword:00000000 <Default is disabled>
Windows 2003/XP –
Fipsalgorithmpolicy =dword:00000000 <Default is disabled>
Enabling this group policy setting effectively disables everything except TLS.
Let’s continue with more examples. A vulnerability report may also indicate the presence of other Ciphers it deems to be “weak”. Below I have built a .reg file that when imported will disable the following Ciphers:
Windows Registry Editor Version 5.00
"Enabled"=dword:00000000 ß We are also disabling the NULL cipher suite as well
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168]
After importing these registry settings, you must reboot the server.
The vulnerability report might also mention that 40-bit DES is enabled, but that would be a false positive because Windows Server 2008 doesn't support 40-bit DES at all. For example, you might see this in a vulnerability report:
Here is the list of weak SSL ciphers supported by the remote server:
Low Strength Ciphers (< 56-bit key)
EXP-ADH-DES-CBC-SHA Kx=DH(512) Au=None Enc=DES(40) Mac=SHA1 export
EXP-ADH-DES-CBC-SHA Kx=DH(512) Au=None Enc=DES(40) Mac=SHA1 export
If this is reported and it is necessary to get rid of these entries you can also disable the Diffie-Hellman Key Exchange algorithm (another components of the two cipher suites described above — designated with Kx=DH(512)).
To do this, make the following registry changes:
You have to create the sub-key Diffie-Hellman yourself. Make this change and reboot the server. This step is NOT advised or required….I am offering it as an option to you to make your server pass the vulnerability scanning test.
Keep in mind, also, that this will disable any cipher suite that relies upon Diffie-Hellman for key exchange.
You will probably not want to disable ANY cipher suites that rely on Diffie-Hellman. Secure communications such as IPSec and SSL both use Diffie-Hellman for key exchange. If you are running OpenVPN on a Linux/Unix server you are probably using Diffie-Hellman for key exchange. The point I am trying to make here is you should not have to disable the Diffie-Hellman Key Exchange algorithm to satisfy a vulnerability scan.
Being secure is a good thing and depending on your environment, it may be necessary to restrict certain cryptographic algorithms from use. Just make sure you do your diligence about testing these settings. It is also well worth your time to really understand how the security vulnerability software your company just purchased does it’s testing. A double-sided network trace will reveal both sides of the client server hello and what cryptographic algorithms are being offered from each side over the wire.
Jim “Insert cryptic witticism here” Tierney