Blog: Android
Move over SHA-1, SHA-2 is coming. Here’s the why and the how
In the coming two years, and starting now, the world of HTTPS certificate signatures is set to become a whole lot more complex.
What’s the big deal?
The SHA-1 crypto hash is going to be replaced by SHA-2, a set of six crypto hash functions, the most popular of these being the 256 bit version. Google is taking the lead with the deprecation of SHA-1, quoting Bruce Schneier on Collision Attacks, and the CA/Browser Forum’s 2011 assertion that all certificate authorities should move away from SHA-1.
The most visible and tangible impact of this will be in browser certificates. Because Google are being so aggressive with the move to SHA-2 their Chrome browser will be highlighting what it sees as deficiencies in SHA-1 SSL certificates starting around mid-April 2015, with the release of Chrome version 42. It will show SHA-1 based certificates marked as insecure, or with issues.
This begs the question: In the period of transition between SHAs 1 and 2 will browsers that continue to accept SHA-1 become a consumer confidence issue?
As a quick ready reckoner the https://shaaaaaaaaaaaaa.com/ site will tell you if a domain is using SHA-1 and provides pointers on getting a SHA-2 certificate as well.
Is doing nothing an option?
There are quite a few compatibility issues between SHA-2 and older browsers / operating systems. For example, Android
The risk of not updating is “training” users to either not trust your site (reduced custom) or encouraging them to accept less-than-perfect encryption or even invalid certs.
…and that’s assuming that users will actually pay attention to an invalid cert warning. We are a savvy audience, but does Joe Public have the wherewithal to identify differences between expired / invalid / forged certs? Man in the Middle attackers are going to love this.
The fact that SHA-2 can’t be used with older browsers and OS’s means that untrusted cert warnings are going to become commonplace. We know from experience that, when users come up against errors and warnings that they cannot fix, those warnings either get ignored or they leave your web site and go shopping somewhere else. People simply give up caring, they become part of the (slightly broken) experience.
iOS has always had awful invalid SSL cert warnings and this hasn’t led to users demanding a fix, they simply ignore them by tapping “Continue”:
With Android the situation is worse. Around 1% of devices used for Play and Google are still
There are potential commercial and trust issues attached as well. If your customer’s account is compromised through a MITM attack conducted against them at a Wi-Fi hotspot, are they going to accept that it’s their own fault for accepting an invalid cert? I doubt it somewhat, and you’ll have an awkward claim to deal with.
To re-iterate: If the certificate is invalid, all guarantees are gone – mutual authentication, integrity, non-repudiation, and confidentiality.
Challenges
Implementing or migrating to SHA-2 will be an “interesting” proposition for anyone tasked with it.
First you’ll need to know which of your apps and devices will actually work with SHA-2. This looks like being zero fun as error messages are not going to conveniently state “Not SHA-2 compatible”. They’re more likely to be oblique at best and misleading at worst. How helpful is a “Bad certificate” error message at the best of times?
Luckily there are some great resources out there, with this InfoWorld post being a must-read:
http://www.infoworld.com/article/2879073/security/all-you-need-to-know-about-the-move-to-sha-2-encryption.html
Browser developers and SHAs 1 and 2
Here’s what the major browser developers have to say about how they’re handling the move to SHA-2, and the timescales they’re working to:
IE: http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx
“Microsoft has announced a new policy for Certificate Authorities (CAs) that deprecates the use of the SHA1 algorithm in SSL and code signing certificates, in favor of SHA2. The policy affects CAs who are members of the Windows Root Certificate Program who issue publicly trusted certificates. It will allow CAs to continue to issue SSL and code signing certificates until January 1 2016, and thereafter issue SHA2 certificates only.”
Chrome:
http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html
“Sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.
“We agree with the positions of Microsoft and Google that SHA-1 certificates should not be issued after January 1, 2016, or trusted after January 1, 2017. In particular, CAs should not be issuing new SHA-1 certificates for SSL and Code Signing, and should be migrating their customers off of SHA-1 intermediate and end-entity certificates. If a CA still needs to issue SHA-1 certificates for compatibility reasons, then those SHA-1 certificates should expire before January 2017”.
VBA and Office Macros
So far no-one has said much about macro signing in all of this. While it has nothing at all to do with browsers it’ll matter to you if you digitally sign VBA objects and macros. Assuring that a document isn’t malicious will become more complex once SHA-2 comes into effect. Signing Office macros is one way of preventing users from falling for phishing scams with Office docs containing VBA malware. Another option is to simply block macros, but this still isn’t perfect. There’s a post about that very subject here if you want to dig deeper
However, SHA-2 compatibility isn’t great; it simply doesn’t work for Office 2003/2007 macro signing. Office 2010 does support it, but only with a hotfix
Going further, there are plenty of systems out there that are unlikely to ever accept SHA-2; what about the web interfaces for SCADA and other industrial control systems? What about other highly customised environments in the military; fire control systems built on old hardened versions of Windows XP?
In Conclusion
SHA-1 has potential collision issues, so is quickly being deprecated in favour of SHA-2. It’s relatively straightforward (if a little time consuming and costly) to deploy new server side certificates, but you are likely to prevent a small proportion of customers who use old tech from transacting with you until they upgrade to a newer operating system.
The alternative is to continue accepting SHA-1, but certificate warnings and errors will be shown to your customers in their browsers. This will likely damage confidence in your brand, teaches poor practice to Joe Public and may expose your clients to man in the middle attacks.
