Please review your crypto

We find we are speaking regularly to people to review their currently configured web transport security configuration.

Its one part of the OWASP top 10: to ensure that the data being transported across the untrusted networks of the Internet are adequately encrypted. The configuration of your web server, and the responses you have (possibly mis-) configured it to give out to anonymous users across the internet may be disclosing vital attack information that helps compromise your systems, and at best, shows a lack of strong policy or understanding.

First and foremost, if you’re not using HTTPS, but the plain-text HTTP, then you’re about to get warnings on your site as being “Not Secure”. Its been present on form submission pages for a few months on Chrome, but now that messaging is going out for all unencrypted web pages.

Why not take 3 minutes and visit SSLLabs.com/ssltest and submit the URL of your company web site. Then repeat this for your company’s AD FS or single sign on service, or Webmail service. It will take about 2 minutes on each, and we can thank Qualys for sponsoring this while we wait…

Now scroll down to the first section, “Summary”, and look for any red or orange bars on the page showing some pretty straight forward warnings. You may have a certificate from one of the previously Symantec-operated or owned Certificate Authorities which, although expiring some time in the future, are actually going to stop working for a large majority of users from September. Better action that ASAP!

Next, scroll down to the section that says “Configuration”: if it shows only TLS 1.2 as being enabled, and everything else disabled, you’re probably doing well.But you’re not Done yet.

If you also have TLS 1.3 enabled, then well done (this version is quite new).

But if you have TLS 1.1, or older, then its time to turn that off. And for some of those, that time to turn off was actually back in 2014. But I understand, you’ve been busy.

Now drop a little further to “Cipher Suites”. You should have a note saying “suites in server order preference”, if not, then you should enable that on your server. And finally, ensure you have a “cipher suite” something like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 very near to the top of our ordered list.

Let me break this down:the cipher suite normally goes something like:

KEY-EXCHANGE_CERT-TYPE_BULK-CIPHER_CHAIN-MODE_MAC

The Key Exchange: ECDHE is good, DHE is average, and DH is bad. Get rid of DH and DHE.

Certificate types: depends on the certificate you generated. Most people use 2048 bit RSA based certificates, but longer RSA is possible (and slower), and the newer ECDSA based (elliptical curve) Certificates are coming soon. RSA is fine for now.

Bulk Cipher: Today, AES 128 or 256 (doesn’t matter which) are considered OK. 3DES, RC4 are really bad. Just leave the AES ones enabled.

MAC: If it just says “SHA”, its bad – SHA-1; if it says MD5, then is terrible! SHA256 and SHA384 are both currently acceptable.

Of course, that’s for today. Last week, we could have left CBC based ciphers in there, but then research from Microsoft showed that’s now not considered secure. But in removing the last of the CBC chain mode suites, you’re probably going to stop MS IE 11 from being able to connect.

There’s other tools (Mozilla Observatory), and a lot more places to look — such as the HTTP Headers than can help secure content, and improvements to HTML as well — that should all be reviewed.

Nephology has been securing ecommerce web systems globally, for commercial and government organisations, since 1995 – from the birth of the web. Contact us for more information.

CBC-mode no longer safe

On 12 June 2018, Microsoft announced Timing vulnerabilities with CBC-mode symmetric decryption using padding. You may not have noticed, but the implications are interesting.

Microsoft’s own web browser story has two characters: the venerable Internet Explorer (IE, or MSIE), and the new kid on the block, Edge. The Edge team is working to try and keep up with the agility that its most active competitors display: Chrome, Firefox, and Safari. However, MSIE does not seem to receive much in the way of new features or even maintenance of existing features. Yet MSIE remains a default browser for a large number of slow moving Enterprise and Government organisations, due mainly to the fact they are still running Windows 7, and have these (typically older) versions of MSIE installed by default.

After 20 years of cryptography on The Web, there is a lot of legacy; the danger is that some of this legacy which was once start-of-the-art is now downright insecure. During this 20 year period (since Netscape Navigator 1.1N brought RSA crypto and x509 to the web), vendors and producers of technology solutions have sought to support newer protocols, ciphers and message digest algorithms, but have not widely removed support for this legacy. This has been coupled with a general lack of understanding by the administrators of web sites and HTTPS terminating firewalls/load balancers, and a lack of agility of the enterprise to appropriately maintain the tools and services they provide to thier staff and users.

Web Crypto Transitions

Let me break this down into several areas of web security that are being maintained:

  • TLS Protocols (how we will negotiate what encryption to use)
  • Key Exchange mechanisms
  • Bulk Ciphers
  • Cipher Options
  • Message Authentication Code (MAC)
  • Certificate chain-of-trust signing Algorithms
  • Certificate key Algorithm

All of these are being replaced over time, and likely will be replaced REPEATEDLY in future, spurred on my discoveries of vulnerabilities in the techniques being used, or simply the declining cost and complexity of brute forcing solutions to these.

Until now, the mere presence of a web browser “green padlock” has hidden the sins of poorly configured web sites.

TLS Protocols

From 30 June 2018, PCI DSS 3.2.1 requires that cardholder environments no longer support ‘early TLS’, meaning TLS 1.0 or older (SSLv3, SSLv2). This leaves just TLS 1.1 and 1.2 available to most, with TLS 1.3 only just starting to become available (see the <a href=”https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/”>IEFT Status</A> for a timeline of its work).

TLS 1.1 was itself released in RFC 4346 in April 2006; 1.2 was released in RFC 5246 in August 2008. During that 28 months, only one Firefox and a handful of Chrome releases had TLS 1.1 as its highest support protocol version. Both of these browsers have had many, many releases in the ensuring DECADE, so for all intents and purposes, most web site providers should be in a comfortable position to ALSO disable TLS 1.1 (but check your web logs first).

MSIE 11 does support TLS 1.2; however for older versions of MSIE, support is either disabled by default (simple option to turn it on), or not available at all. Java 6 updated 141 does support TLS 1.2 by default, but not necessarily the modern key exchanges, ciphers and MACs).

Key Exchange Mechanisms

Asymmetric Encryption is used to exchange information between parties over untrusted networks. This is a computationally complex process (slow), so is used to share the names and keys that are used for symmetric bulk encryption.

  • Straight Diffie-Hellman (DH) key exchange was the first stab at this, but it used the same private key for all exchanges.
  • Diffie-Hellman Ephemeral (DHE) was the fix to this; a new key used each session.
  • Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) now uses elliptical curve mathematics to speed this up.

However, MSIE does not support ECDHE, and neither does Java 6 out of the box with the default cryptographic provider (you can look to replace with, say, Bouncy Castle).

Bulk Ciphers

Bulk symmetric ciphers use the same key to encrypt and decrypt, but are generally fast. Today we seem to have settled upon using AES 128 or AES 256; newer ciphers such as Whirlpool are around, but not widely implemented server & client side, so not used.

Cipher Options

The biggest impact of the above MS announcement is that CBC – Cipher Block Chaining, is now deprecated. In its place stand Galois Counter Mode (GCM). GCM is not (at this time) supported by MS IE, or Java 6 default JCE.

MACs

SHA-1 based MACs have largely been dropped today, replaced by SHA-2-256. However, some organisaitons are now raising their minimum to SHA-2-384, which is beyond the capability of MSIE and of Java 6.

Certificate Chain of Trust

Over the last few years, the signing algorithm used to confer trust from a Certificate Authority to a subject’s certificate has moved from MD5withRSA, to SHA1withRSA, and now sits at SHA256withRSA. This remains to be well supported.

Certificate Key Algorithm

The certificate that sites present is currently based upon the RSA signature algorithm, and using a key length of 2048 bits. While this key length can in future be made longer, it gets much slower.

In its place will be newer ECDSA based keys. Its possible that over time, servers will have both RSA and ECDSA certificates at the same tie, and will serve the one based upon the client’s expressed cipher suite preference during connection establishment.

CBC-mode no longer safe

Circling back to the CBC mode for AES being deemed no longer safe, what does this mean. For sites that take this seriously, it means moving to only GCM based block chaining. For many, that means the end of supporting Microsoft Internet Explorer, as well as any system-to-system integrations that run from a Java 6 environment.

That’s too bad, but its not like those Java 6 services haven’t had since 2011 to move to Java 7, or since 2015 to adopt Java 8. We’re now at a point where good security practice must force these environments to comply to current requirements; and organisations that apply an Agile methodology of frequent, small updates and continual True Maintenance (ie, not just application functionality updates, but underlying VM/JVM/runtime environment updates).

We recently heard of one of Australia’s Big Four banks start to ask its customers to increase their protocols, ciphers, chaining options, and even MACs.

While TLS 1.2 is reasonably well supported, even on old Java, the move to GCM and SHA384 MAC was well beyond what Java 6 can do out of the box. Its a strong move, but need to be well communicated with clients, probably 6 months in advance. Luckily, this bank regressed to continuing to support CBC and SHA256 MAC, but with this news, CBC may once again be on the chopping block soon.