Google accelerates end of SHA-1 support; certificate authorities nervous

Summary:UPDATED. Google is consciously using their influence to push certificate authorities to advance security standards soon. Would you believe the problem is Windows XP SP2?

Google's recent announcement that they will begin to deprecate support for SHA-1 TLS/SSL digital certificates in Chrome is meeting resistance from certificate authorities (CAs).

Google made their announcement on August 20 on their Security-dev mailing list, although they had been warning of this decision for months.

SHA-1 is a hash algorithm, a critical component of secure cryptography. A hash algorithm takes a block of data as input and outputs a value of a certain size (SHA-1 hashes are 160 bits long). This value is called a hash or digest. With a good hash algorithm, two different blocks of data will always produce a different hash, and even a small change in the input data will result in a significant change in the output. There should be no way to learn anything about the input data from the hash output.

Over time, security standards usually become less effective for two reasons. Research finds weaknesses in them, and the plummeting cost of compute power makes computationally difficult attacks more practical. SHA-1's predecessor, MD5, was in use well beyond the point that attacks on it were cheap and easy.

There are no practical attacks on SHA-1 yet, but it's just a matter of several years before they appear. This means that we have time to move on beyond SHA-1 before problems hit the real world. The next standard up, SHA-2, is a series of hash functions with several hash sizes: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256. There is also a SHA-3, but it is a very young standard with no commercial implementations.

The move to deprecate SHA-1 began in earnest with  an announcement by Microsoft last November  that they would begin to withdraw support for SHA-1 in their root certificate program starting January 1, 2016, and would end support for SHA-1 SSL certificates by January 1, 2017. Code signing certificates with SHA-1 hashes will no longer be accepted by Windows on January 1, 2016.

The CAs, at least as represented by the CA Security Council (CASC), have been publicly supportive of Microsoft's policy. Google has decided that quicker action is necessary.

Google's proposal is to make the following changes to Chromium's handling of SHA-1 (this is a quote):

  • All SHA-1-using certificates that are valid AFTER 2017/1/1 are treated as insecure, but without an interstitial. That is, they will receive a degraded UI indicator, but users will NOT be directed to click through an error page.

  • Additionally, the mixed content blocker will be taught to treat these as mixed content, which WILL require a user action to interact with.

  • All SHA-1-using certificates that are valid AFTER 2016/1/1 are treated as insecure, but without an interstitial. They will receive a degraded UI indicator, but will NOT be treated as mixed content.
https.error

So when this is implemented in Chrome and a user browses using https to a site with a SHA-1 certificate that is valid after January 1, 2016, the Chrome UI will show the lock with a red "x" and the https with a red slash through it, as shown nearby.

Updated on September 2: Google has clarified the schedule for the deprecation. They note that it is an announcement of "intent," not a "promise" to implement these features on this schedule. They are seeking input. The clarified plan for the changes has them beginning in Chrome 39 (released to the stable channel roughly 9-12 weeks from now) and spread out through Chrome 41 (21-24 weeks from now). Click the link just above for all the details. 

Remember, from 1/1/2017, Microsoft will stop supporting SHA-1 certificates and there seems to be general agreement that this will be the effective end of the line for them. Nevertheless, under the CA/Browser forum guidelines, it is acceptable for CAs to sell SHA-1 certificates with lifetimes past that date. Consider the experience of Google's Mike West who just bought a five year SHA-1 certificate from a Comodo reseller.

When will Google implement this change? I would argue that this is unclear, but the CASC is claiming that the schedule is for Chrome 39. The current stable version is Chrome 37. I'm told by a Symantec employee that Google gave Chrome 39 as a target in a recent conference call of members of the CA/Browser Forum. And in a mailing list discussion on August 12, Ryan Sleevi, a Senior Software Engineer at Google who works on the cryptography in the Chromium platform, certainly seems to say that he's planning to implement the change in Chrome 39.

Must See Gallery

10 technologies that made me more productive in 2014

Hardware. Software. Services. We live in amazing times, and the technologies we use every day would have been considered magical just a few short years ago. Here are 10 small pieces of magic that made my life easier this year.

In fact, the first dev and canary builds of Chrome 39 came out over the weekend and they do not implement the proposed behavior. Sleevi says that it is not implemented and that "... it is still under active review and discussion." There is a defined process for feature deprecation in Chromium. It looks long and complicated and getting it done by Chrome 39 looks tough to me.

The CASC says, based on the assumption of an implementation in Chrome 39, that Google is being too aggressive. The schedule for Chrome 39 would see it released to the stable channel in or about late November, at the height of the holiday shopping season. If consumers start seeing what looks like an HTTPS error, which they have been told to take as a warning of potentially fraudulent activity, the result could be lost sales for commerce sites.

My personal opinion on this is mixed; implementing this policy before the holiday season is safely over would be a mistake and unfair for two main reasons: the CASC is right that it would cause a lot of user confusion at a bad time, and it's just unfair to implement such a change with so little formal notice.

But beyond that, I'm completely on Google's side. The CAs have generally had to be forced into implementing security advances by the major software companies, virtually at gunpoint. The CAs, in this context, are just a proxy for users. CAs have no reason to object to advancing standards unless it loses them business. Their objection now is that there are still customers who "need" SHA-1 certificates, so if they stop selling SHA-1 the customers will just take their business elsewhere. (Incidentally, this episode is, if you ask me, proof of strong competition in the digital certificate market.)

Who, in this day and age, needs SHA-1? To a small degree there's a problem of old security appliances and point of sale terminals that haven't been, or maybe even can't be updated, but that's not the real problem. The real problem is Windows XP SP2. Yes, SP2.

An employee of Cloudflare, a CA (although that's not their main business), responded to the Google announcement with this: "... a large percentage of the web visitors of our customers are using Windows XP SP2 which does not support SHA-256." This is also what the CASC told me.

It's hard to tell someone using Windows XP SP2, which reached end of support over four years ago, that they are insecure because of limitations in their cryptographic hash support. At least it's difficult to tell them that with a straight face. Clearly such users have bigger security problems than a lack of SHA-2 support.

No, this is purely a business problem. Those users are determined not to upgrade their OS. And as long as that's the case, the CAs will give the people what they want.

The CAs are very happy to sell SHA-2 certificates, and they report that those sales are growing rapidly. But they still sell a lot of SHA-1 and they sell those certificates with long lives. Google's Sleevi did some counts based on company telemetry and found that all the large CAs have issued large numbers of SHA-1 certificates with lifetimes into 2016 (almost 670,000) and even into 2017 (almost 300,000).

So if Google really is thinking of rolling out this change before the new year, they're making a mistake. It's unfair and unnecessary. But going more aggressive than Microsoft's schedule? Nothing wrong with that. The more time you give users the more they'll take and then complain that you're not giving them even more. It's always this way. So an aggressive Google is doing the CAs a favor. CAs can't make their customers use better security, but Google can.

Updated on September 2: Since Google has clarified their schedule to confirm that the changes are planned to be well in place by the holiday season, I'll repeat my objections. They would be well-advised to slip these changes ahead two releases. It's worth noting that the point of the changes right now is not to help the user directly, but to put pressure on site owners and certificate authorities by threatening them with user confusion. A SHA-1 certificate that expires next week is no more secure today than one which expires in 2017. It's only fair for Google to give more time than they are now giving. https://www.google.com/ itself uses SHA1 in its certificate although Google's certificates have only a three month life. Google can do the three month life span because they are their own certificate authority. Smaller companies must pay for certificates, which are cheaper with longer life spans.

Topics: Security, Browser, Google

About

Larry Seltzer has long been a recognized expert in technology, with a focus on mobile technology and security in recent years. He was most recently Editorial Director of BYTE, Dark Reading and Network Computing at UBM Tech. Prior to that he spent over a decade consulting and writing on technology subjects, primarily in the area of sec... Full Bio

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.