A better way to move past insecure SHA-1 certs

I’ve written a few times about the pending mini-Y2K issue that is SHA-1 deprecation. In a nutshell, all digital certificates are signed by a hashing algorithm — and SHA-1 is the signature type used by almost everyone.

But SHA-1 has significant cryptographic weaknesses, which is why the crypto world has recommended for years that digital certificates use its chosen successor, SHA-2, instead. You can find great threat modeling discussions regarding the potential impact of a full SHA-1 break in this piece by Google’s Ryan Sleevi and another by Eric Mill of the GSA organization 18F.

As far as we know, SHA-1 has not been completely broken yet (although massively funded private parties might have done it in secret). But any vendor that really cares agrees that 2016 and 2017 will be the years when applications, devices, and customers are forced to move to SHA-2.

Hiccups now, chaos later

Starting Jan. 1, 2016, some of the applications and devices that rely on digital certificates will begin issuing some sort of warning if the digital certificate contains a SHA-1. Some applications, such as those from Google, have been doing this since 2014.

By Jan. 1, 2017, many applications and devices will error out or cause some sort of operational interruption if targeted types of digital certificates are signed by SHA-1 only. Unfortunately, each vendor will have its own SHA-1 deprecation treatment and schedule. Some vendors care only about TLS certs, others care about TLS and code-signing, and others care about any type of digital certificate. Some vendors say their deprecation treatment will apply only to public certs, others say to both public and private certs. Some are waiting until Jan. 1, 2017, and some are moving up dates.

There are distinct, important differences among major vendors. Worse, other vendors are either unaware of the coming enforcement or haven’t publicly announced their treatment. Digital certificate users tend to be the most clueless of all — and won’t know what’s going on until the warnings and interruptions start. It’s a mess at the moment.

No one knows exactly how many applications and customers are ready, but a few studies point out some of the pain points. For example, CloudFlare predicts that up to 37 million browser users could be at risk if SHA-1 were to be completely deprecated. Facebook puts the number even higher. This is browsers only; very likely millions of applications and devices will not understand SHA-2.

People involved in current SHA-1 deprecation projects know that critical applications will not work with SHA-2 — and customers who aren’t prepared will suffer service interruption issues. I’m involved with a few customers who are deeply concerned with the coming SHA-1 deprecation deadlines. They have major critical applications that will not be ready in time.

Vendors understand their customers’ dilemmas, but at the same time, most feel too much time has passed already, and the hard work and pain needs to happen sooner rather than later. That said, no vendor wants its customers — especially big clients — to endure operational hardship.

Staking out a middle ground

On that note, some major vendors are proposing a middle-ground, lifeline solution called Legacy Verified Certificates to the CA/Browser Forum, the organizational body leading SHA-1 deprecation decisions. Unfortunately, no previously issued SHA-1 certificate would qualify, but adopting Legacy Verified Certificates would be easier than a wholesale switch to SHA-2.

If the draft is approved by the CA/Browser Forum, only newly issued certificates, which must have the following traits, are allowed:

• Policy Identifier field value of 2.23.140.1.2.99
• Nonsequential Certificate serial number with at least 20 bits of random entropy
• Expiration date no greater than March 31, 2019

The 20 bits of randomness are needed to reduce the likelihood of the types of attacks that could occur against SHA-1. If accepted, this proposal effectively lengthens the SHA-1 deprecation deadline (for apps recognizing Legacy Verified Certificates) to the end of the first quarter in 2019.

I can tell you this proposal would be greatly appreciated by every customer I know of. There’s almost no downside. Customers who wish to participate must create or request a certificate meeting the Legacy Verified requirements; otherwise, the original deprecation treatment applies. It’s an opt-in policy, so the people proactively opting in understand the risks and agree to accept them.

If there is a downside to Legacy Verified certificates, it’s that it creates yet another SHA-1 deprecation exception that some vendors may or may not accept. Amid already complicated deprecation plans, this adds one more wrinkle and potential test scenario. I can see some vendors and some customers pulling their hair out from any change or addition, even a good one.

Personally, I like the Legacy Verified proposal because I believe it will reduce disruption — and I hope the CA/Browser Forum passes it.