IIS Crypto 1.4 has finally been released. Along with the usual bug fixes, version 1.4 adds in a new Best Practices template which prefers forward secrecy cipher suites with the highest key length. The BEAST template has been removed as RC4 is now considered much weaker than previously was known. A good explaination can be found here. Finally, the SSL scanner from Qualys is now built in so you can scan your website directly from IIS Crypto.
NOTE – This post is outdated. For a full list of registry keys, see our updated FAQ.
Lately, we have been receiving a lot of questions with regards to what exactly IIS Crypto does. I will do my best to answer these questions in this post.
IIS Crypto was created to simplify enabling and disabling various protocols and cipher suites on the many servers we administer. Originally we had a script that we would execute on each server after the initial setup, however, some servers needed different protocols and cipher suites enabled. We also wanted to see the current configuration of existing servers. Thus IIS Crypto was born.
IIS Crypto simply sets a few registry keys to enable/disable protocols, ciphers and hashes as well as reorder cipher suites. Microsoft has an article explaining all of the settings here. These are the exact keys IIS Crypto uses:
HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsMulti-Protocol Unified HelloServer HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsPCT 1.0Server HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Server HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Server HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Server HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersNULL HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersDES 56/56 HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 40/128 HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 56/128 HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 128/128 HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 40/128 HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 56/128 HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 64/128 HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 128/128 HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168 HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersAES 128/128 HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersAES 256/256 HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELHashesMD5 HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELHashesSHA HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELKeyExchangeAlgorithmsDiffie-Hellman HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELKeyExchangeAlgorithmsPKCS
Each registry key has an “Enabled” value that is set. The protocols have an additional value named “DisabledByDefault” that is also set.
To reorder the cipher suites, IIS Crypto uses the following keys:
The first registry key contains the list of supported cipher suites on the server. The second registry key is used to set the cipher suites order. These are the same keys that the group policy editor (gpedit.msc) use. Microsoft explains how to do this manually here. The full list of cipher suites supported is here.
IIS Crypto also supports pre-defined templates that can be set with a single button click:
PCI – Disables everything except SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, RC4 128, Triple DES 168, AES 128, AES 256, MD5, SHA1, DH and PKCS.
FIPS 140-2 – Disables everything except TLS 1.0, TLS 1.1, TLS 1.2, Triple DES 168, AES 128, AES 256, SHA1, DH and PKCS.
BEAST – The same as PCI, but also reorders the cipher suite as follows:
TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Feel free to leave a comment if you have any questions.
IIS Crypto has been updated to fix the security exception issue if it is run under a non-administrator account. Thanks for all of the bug reports, keep them coming!
Microsoft has issued an advisory (2588513) to enable TLS 1.1 on both the client and server. This all stems from the recently disclosed vulnerability in the TLS 1.0 protocol. One of the main reasons why we wrote IIS Crypto was to make it easy for administrators to enable TLS 1.1 and 1.2. We are happy to see Microsoft take this issue seriously and hope many server administrators will as well.