Getting an A+ on the Qualys SSL Test – Windows Edition
My previous article has gained a lot of attention as a reference point on how to score the highest A+ rating on the Qualys SSL Test. In doing so, site admins are ensuring that the TLS configuration on their server offers up to date and robust security to their users. Focused around my own NginX install on Ubuntu, my previous article didn't cater for Windows Server admins. This is for you guys!
Setting up on Windows
Most of the configuration here takes place in the registry but I've used a nice little tool in the past to give me a GUI for configuring TLS settings. IIS Crypto, a free tool from Nartac Software, makes configuring everything just a few clicks instead of manually creating and modifying registry key values. Grab yourself a copy from the link to get started.
Following on from my previous blog on POODLE, the choice of protocols we should use has been taken from 4 down to 3. Those are the TLSv1.0, TLSv1.1 and TLSv1.2 protocols. Go ahead and select those in the 'Protocols Enabled' section.
This section allows you to narrow down the range of cipher suites for later refinement and ordering. The only options I'd recommend selecting here are the 3DES, or Triple DES, suites and both AES selections. The use of RC4 suites is now questionable, RC2 and DES should not be used and NULL ciphers offer no protection at all!
Like the Ciphers Enabled section, this section allows you to further narrow down the ciphers suites you have available based on the hash algorithm used for Message Authentication Codes. In this section, MD5 should be disabled as it is now proven to be too weak but any variant of SHA is currently acceptable for use.
Key Exchanges Enabled
All of the listed options for key exchange mechanisms can be selected. The Diffie-Hellman and PKCS (Public Key Cryptography Standard) options use the time tested RSA key exchange and the ECDH (Elliptic Curve Diffie Hellman) option uses ECC (Elliptic Curve Cryptogrpahy) instead.
Cipher Suites Ordering
The ordering of your cipher suites can have a huge impact on the effectiveness of your TLS implementation. It can be the difference between having Perfect Forward Secrecy or not, based on which cipher suite your server prefers the most. ECDHE (TLS_ECDHE_RSA) suites should be prioritised over all others as they offer PFS support and are faster than the DHE equivalents. You can then follow these with DHE (TLS_DHE_RSA) suites to offer robust PFS support for slightly older devices and browsers too. After we've prioritised suites that give us PFS, you can introduce RSA for the key exchange (TLS_RSA) for clients that don't support ECDHE or DHE suites. All that will leave you with is cipher suites for use with ECDSA certificates (TLS_ECDHE_ECDSA). If you don't have an ECDSA certificate, and the chances are you don't, then you could disable these cipher suites as they will never be negotiated. That said, there isn't really any harm in keeping them for exactly the same reason. The last thing to check is that the TLS_RSA_WITH_RC4_128_SHA suite is disabled. Here are the cipher suites in order.
All you need to do now is hit the 'Apply' button and restart the server for the registry changes to take effect. It's a bit of pain on Windows to have to reboot the server instead of just reloading the configuration but it can't be avoided. Once your server has rebooted you can head over to the Qualys Test and check the score for your domain. Everything so far should get you up to an A, read on to get it up to an A+.
OCSP Stapling is enabled by default and is supported on Windows Server 2008 and later. Whilst it doesn't directly affect your Qualys SSL score, it is highly recommended that you utilise OCSP Stapling for the benefits I've outlined in the linked article. Fortunately, you don't need to do anything for this one!
Perfect Forward Secrecy
Perfect Forward Secrecy is a feature of certain key agreement protocols that can protect encrypted session data even in the event of a compromise of the server private key. By supporting and prioritising ECDHE and DHE suites, your server will have robust support for PFS.
SHA1 VS SHA256 Certificates
Google recently announced that following the deprecation of SHA1 in 2011 they are starting the sunsetting process for the cryptographic hash. Announced on their Online Security Blog, users will soon start to see various HTTPS warning indicators on websites that still use SHA1 certificates or chains that contain SHA1 certificates. You can read more details in the linked article. Due to this, Qualys have updated their SSL Test to indicate when a certificate, either the leaf or a certificate in the chain, is using SHA1. Using a SHA1 certificate will now prevent you from getting an A+ and you will see something like this.
To prevent this you will need to replace any SHA1 leaf certificates and update your certificate chain to ensure that any intermediate certificates are also SHA256. The root certificate in the chain does not need to be SHA1.
(Updated 11th Jan 2015)
TLS_FALLBACK_SCSV is a Signalling Cipher Suite Value (the SCSV part) that allows a browser to indicate to a server when the current connection attempt is a fallback attempt. When present in the client hello, the server knows that the connecting client can use a better protocol than it is currently connecting with and will reject the connection. TLS_FALLBACK_SCSV gained a lot of popularity after POODLE as it would prevent clients that supported TLS from being forced back to SSLv3 to be attacked. It's a great feature to support on your server as it will prevent a client being forced back from TLSv1.2 to TLSv1.1 for example. We don't really want to be in a situation where an attacker can dictate the protocol we use to communite so TLS_FALLBACK_SCSV is highly advised.
Unfortunately, changes to the Qualys SSL Test since I started writing this article now require TLS_FALLBACK_SCSV support to get an A+ rating, but Microsoft has not released support in IIS. This means that all Windows Servers will be capped at an A rating until support is introduced. Thanks to Nick Lowe for pointing out these changes on Twitter. I will update the article again once this feature is supported in IIS.
Update: Ivan Ristic, creator of the Qualys SSL Test, has confirmed that you can get an A+ by only supporting the TLSv1.2 protocol. This technically means that your server isn't vulnerable to protocol downgrade attacks as there are no protocols to downgrade to! This may not be ideal for everyone and waiting for TLS_FALLBACK_SCSV support may be the only choice.
Strict Transport Security
Everything I've covered so far will get you an A rating on the Qualys SSL Test. To improve that rating to an A+ you need to issue a HTTP Strict Transport Security policy. I've covered HSTS before (HSTS – The Missing Link In Transport Layer Security), but in essence this little HTTP response headers allows a host to tell the user agent to enforce SSL on their site without depending on things like 301 redirects. To issue a HSTS policy, all that we need to do is add a custom response header. Open up IIS Manager and navigate to the site that you want to add the header to. In the Home window, double click on the 'HTTP Response Headers' icon.
Once there, click the 'Add' button in the 'Actions' pane.
Now we need to fill out the details for our new custom header. The header name is
strict-transport-security and the minimum we require in the 'Value' field is the
max-age directive to make it a valid policy. This is the length of time that SSL/TLS will be enforced on the site and I use the value
31536000 which is 1 year (in seconds). That would give you
max-age=31536000 in the 'Value' field. To take HSTS one step further, you can also include the
includeSubdomains directive, which tells the browser to apply the policy to all subdomains of the site issuing it, as you probably guessed! This gives a 'Value' field of
Click OK to add your header and we're all good to go! If you like, the header can also be added in the
web.config like so.
Now that's done, run your site through the Qualys SSL Test and check out your results.