The Joy of Ciphers (Revisited)

Old world vs. New world
Some time ago I discussed some of the cipher configurations in Windows 8.1 Enterprise, and with the unwelcome (to most) arrival of Windows 10 I thought I'd see if the landscape had changed. After all if we can prevent outdated modes of security at point-of-source, we're helping encourage a more secure and private internet.

Last time I discovered that when enforcing transport layer security by restricting cipher suites available to Windows and [at the time] Internet Explorer, a core set of websites and Windows services held everything back by requiring significantly lower security cipher levels. It wasn't just one or two periphery services either - a major CSP's hosted email service and the Windows Store.

A chain is only as strong as it's weakest link after all.

During 2016 some of our systems were the subject of attempted breaches. Thankfully they didn't get past the first layers of defence (and of course it goes without saying that nothing was accessed, leaked or stolen), but it was a wake-up call that removed any complacency we might have had. We'd already started moving away from Windows for communications components, e.g. email, and this further justified the infrastructure hardening.

Since then the wider community has finally accepted that SHA1 is not fit-for-purpose and so we can revisit a lot of the requirements for Windows 10. Hopefully with the recent publicity on SHA1's weaknesses organisations like Microsoft and Godaddy will be motivated into removing the weaker cipher options. However that ultimately depends on how quickly these organisations can move - bear in mind that it is quick difficult to take advantage of a weak cipher in the context of a TLS tunnel, as an enemy actor would need to control infrastructure between the consumer and provider of a service. Not easily achieved although slightly more possible on landscapes such as public WiFi.

On Linux distros such as Ubuntu you also may want to consider moving browser choice to Firefox and 'cleaning' the CA trusts out - I don't know that I trust any transaction from Turkish CAs or data slurping behemoths Equifax or Experian as CA's - certainly not from Comodo, WoSign (or any other Chinese CA) and Symantec after their activity in the last few years.

The choice of which CA to trust is yours, and on Debian-based systems you can configure the Mozilla-backed cert list using:
sudo dpkg-reconfigure ca-certificate

Firefox also allows a great deal more configuration than other browsers we evaluated across multiple operating systems. Now back to ciphers. My previous article focused on Windows so I'll return there for this article too - I don't full trust the changes in Windows 10 but am now largely using it across the board. "Why?" I hear you ask? Because 8.1 app store purchases don't seem to work any more and there is less-and-less support. The main reason I've started switching our systems across is that going forward the support for our Surface devices on 8.1 Enterprise is reducing daily.

All the Surfaces are dual boot and Windows is designated for a non-email usage policy, MS Office and collaboration activity policy (client workshops, OneNote, Microsoft Wireless Display Adapter). The additional security software on Windows locks down the browsers too. These choices eradicate a large percentage of threat vectors whilst other actors work to weaken the internet's security strengths.

The point I'm trying to get to is that restricting the list of ciphers available to devices in your enterprise landscape is only one small cog in a very big machine. There's no such thing as a silver bullet. We're going to use Group Policy to apply these settings in Windows 10 so you can manage it on an enterprise-level or per-device. I recommend you test thoroughly on one device of each type in your landscape before rolling this out at enterprise level.

To open the policy editor, run the following command as an administrative user:
gpedit.msc

Alternatively open an administrative command prompt / powershell via Win + X, or Win + S and type "gpedit.msc" - then right-click the resulting entry and select "Run as Administrator".

This guide focuses on application to a single machine so open the Computer Configuration > Administrative Templates > Network > SSL Configuration Settings "SSL Cipher Suite Order" key to access the plain-text list.

The list below is a sub-section of the whole list as I want to focus on two unwelcome additions from last time:
TLS_RSA_WITH_AES_256_CBC_SHA *GoDaddy email servers
TLS_DHE_RSA_WITH_AES_128_CBC_SHA *Windows App Store

So the first weakness we can take out is the RSA-AES256-SHA1 cipher needed for Godaddy as we no longer use them. There are many providers of webmail available from Google to ProtonMail - with a vast range of privacy and security between. Retaining a local mail store is no longer a safe option - mitigate that to a provider or roll-your-own in AWS, Azure, Office365 or Google Apps / For Work.

I've tested these on our local testbed and have successfully removed both without adverse effect. Don't take my word for it - test it thoroughly yourself.

The DHE-RSA-AES128-SHA1 cipher needed for the Windows store also now seems suspect and has also been removed although replaced with a non-SHA1 variant of RSA-AES-128-CBC. The previous DHE-variant no longer seems to allow XBox Live but seems to be fine for the Windows Store. You'll need to assess whether you use either of these platforms at all. No UWP requirement? Don't use the store then.

I'm not convinced about DSA / ECDSA as they're not widely recommended for SSH keys - partly due to the low bar set by the key size in SSH keygen but also concern over potentially compromised implementations. I need to research a little more on the EC front before making that decision.

So the final list should look something like this:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256 *Upgraded cipher for Windows Store, Office & Xbox Live
TLS_DHE_DSS_WITH_AES_256_CBC_SHA, *Removed from the previous articles list
TLS_DHE_DSS_WITH_AES_128_CBC_SHA *Removed from the previous articles list

No more SHA1 variants (or SSL, MD5, RC4) allowable through the main Windows pipe. Watch your event log for Schannel errors - you may need to adjust your cipher order again if other systems require it. The Schannel errors are purposely cryptic so you'll need to repeat actions and check for errors in the log until you isolate the system involved.

If you have systems whose vendors are preventing you cutting off obsolete ciphers I'd recommend engaging them directly; if their worth their salt (!!) they'll have a mitigation plan already, or be planning resolution via upgrade path. 

I'll be looking at the similar ordering configuration for elliptic curve ciphers another time - that's the "ECC Curve Order" key in the same location as "SSL Cipher Suite Order". The issues discussed in that post will relate to the suspected weakening of particular cryptography overall, and the impact on the recommended ciphers.

Until then you may find the following command illustrative in your own choices:
CertUtil.exe -DisplayEccCurve

Whatever your choices from this point, make sure you apply an annual review as part of your ongoing information assurance policy.

Comments

Popular posts from this blog

Scam Warning - SpellJobs.com

[Belated] Naughty List 2016

Scam Alert - Ian Burrows a.k.a. Alex (P) Haynes (Updated)