Weak defaults in IIS 8 cryptography (TLS/HTTPS/SSL)

So, this isn't exactly a breaking news headline. IIS isn't the most secure web server in the universe. However, it came as a shock to get a "C" grade on testing our school's management information system portal on Qualys' rather awesome SSL Labs tester.

Even if you're not governed by things like GDPR or POPI, it should be a point of ethical professional practice to ensure there isn't a hole large enough to drive a bus through in your security infrastructure.

Fortunately, there's a really easy way of fixing this.

First of all, pick an https:// site you want to check the vague security level of - probably one of your own! Put it into https://www.ssllabs.com/ssltest/analyze.html and see what score it gets.

Reading about securing IIS protocols and cipher suites (i.e. getting rid of the really crappy ones that get you bad compatibility grades), I found this article, which lead to a rather awesome little tool from Nartac that makes it quick and easy to set various registry settings, and gets you from the  "C" quality default IIS 8 settings on Server 2k12r2 C grade to an "A".

Getting an A+ is going to take more work, as you've probably going to have to remove all "weak" ciphersuites (best practice settings below don't, but ensure broader compatibility) and use things like CAA, HPKP and HSTS. If you want to see a domain that gets an A+ at the time of writing, see this; you'll notice some ancient things fail to negotiate a connection because they're too old for the allowed protocols/cipher suites (and should not be used anyway).

To get your A grade, simply apply the Best Practices template settings (unless one of the other templates is more appropriate to your environment, or you know what you're doing and have even more secure settings in mind), reboot, and re-test.

As easy as 1-2-3 reboot!

Doing this helps your less informed site visitors who have browsers that either fail to connect (because they're too unsafe to even allow on the Internet) or better ones with poor cipher suite choices to force reasonably secure connection parameters over TLS 1.2+ (rather than say deprecated SSL 3.0).

Microsoft's official line on this is in this article.

If you want a quick overview of doing SSL/TLS right, Qualys has a nice, straightforward guide.

While you're at it, consider implementing compatibility with DNS-based CAA, which is now a (madatory) practice - but ensure you understand what it does and how to correctly use it in your environment. It's not mandatory to have it (yet) but good CAs must check for it and abide by the rules - so it makes sense to restrict this as much as is sensible for your domains relative to the CA(s) you use. Basically, you tell the Internet who valid CAs are for your domain, preventing any old certificate being valid/issued. You can also consider HSTS/HPKP and DNSSEC/DANE if you want to go to the next level, and they are appropriate in your environment.

Worryingly enough, this post came about from a discussion about Internet Banking security. We were not impressed by what banks are doing - they're mostly behind the curve, and have some pretty dumb opinions on Internet security. They also like to make the lack of security your problem in their terms and conditions. :/