On August 19, Google announced a new policy that accelerates the deprecation of SHA-1 certificates, potentially causing websites using SHA-1 certificates to display warnings in the near future. With the change, Chrome 39 will show a warning for sites that have a SHA-1 certificate expiring in 2016 and require a click through warning for sites with a SHA-1 certificate expiring in 2017 or later. This proposal is scheduled for Chrome 39, which could be released as early as 12 weeks from now.

Although the CA Security Council (CASC), comprised of the seven largest Certificate Authorities, supports migration to SHA-2, members are concerned about the impact on website users and administrators alike. Considering many users may still use software lacking SHA-2 support, primarily Windows XP SP2, and the still unknown impact on a complete SHA-1 migration, this 12 week timeline is aggressive. In addition, many devices still lack SHA-2 support, making necessary possibly unplanned and expensive upgrades.

With fall shopping season nearly here, this policy may be particularly concerning for small internet stores, which could be impacted just before the holiday rush. Because many large sites have lockdown periods leading up to the end of the year, companies that have not transitioned may find themselves restricted from making the move until January, or beyond, due to lack of SHA-2 support. Although a migration to SHA-2 is necessary as computing power increases, because of the significant impact in migration and the lack of a practical attack until 2018, the CASC members recommends the timelines announced by Microsoft in November 2013, which deprecate SHA-1 in code signing certificates by January 1, 2016 and in SSL certificates by January 1, 2017.

To avoid warnings, the CASC recommends that all website operators accelerate their SHA-2 deployment where possible. At the same time, the CASC urges Google to consider the circumstances of website operators and adjust its implementation timelines to match the January 1, 2017 deprecation dates. CASC members remain committed to helping their customers fully migrate to SHA-2 as needed to support the customer’s operations.

  • This article is wrong in almost every detail! First, the Chrome developers made CAs aware of this policy in February 2014, so they have had 9 months to prepare (not 12 weeks). And the deprecation of SHA1 was first agreed in 2011, yet many CAs have done nothing about it.

    Secondly, Chrome is following *exactly* the same timeline as Microsoft. “Windows will stop accepting SHA1 certificates by 1 January 2017.” From Chrome 39 (to be released Nov 2014), any certificate which falls into that category, will receive a yellow triangle: “secure, but with minor errors”. The next release of Chrome (sometime after the holiday season) will treat such certificates as neutral, and apply the yellow triangle to certificates with an expiry in the second half of 2016. Finally, Chrome 41 (sometime in the first half of next year) will, for those very same certificates that Microsoft will stop accepting, display a red cross: “affirmatively insecure”. And the yellow triangle will in Chrome 41 be applied to any SHA1 certs with an expiry in 2016. No click-through (“interstitial”) warning at all. And the same timeline as Microsoft announced last year, but with a clear description of the gradually increasing warnings to be applied.

    Thirdly, suggesting that the tiny minority of users of Windows XP SP 2 should be allowed to hold back the security of the entire Internet is scandalous. SP 3 was released in May *2008*! These users have not updated in 6 years; what makes you think they’re going to do so in the next 2? Remember, while any browser is accepting SHA1 signed certificates, we are *all* vulnerable to collision attacks. (It doesn’t matter if I normally use a SHA256 cert; if an attacker can find a cert that SHA1-collides with my site, they can impersonate me, so long as browsers accept SHA1. *Everybody* has to upgrade to mitigate the weakness.)

    Fourthly, a very simple mitigation for the time being is to ensure that all SHA1 certificates have a “notAfter” date of 2015-12-31 or earlier. This will avoid all browser warnings, and gives you well over a year to actually transition.

    Google and Microsoft (and Mozilla and Opera, who are also onboard) are to be applauded for pushing this essential security transition through in a timely manner. By gradually ratcheting up the warnings, we can smoothly transition. And get this done *before* a practical attack is feasible, and we are left scrambling to update everything “yesterday” (as happened with MD5). Unfortunately, it rather looks like it’s the CAs that have been dragging their feet…

    • Steve Medin

      Toby’s correct about the click-through, the interstitial. Ryan made a clear statement in the blog post in response to requests from CABF. This article should be updated to Ryan’s detailed explanation so that we don’t need to manage confusion across CA customer broadcast messaging and media sources. The only click-through that will occur is once mixed content is presented on a page that has multiple certificates from different servers and the differing expiration dates and SHA-1 usage for those certificates would cause different UI indicia when displayed as single-source content.

      But Toby, one thing we’ve witnessed about Microsoft over these years is that when a deadline is set it is consistently a point in time event. That is, Microsoft took the lead to get SHA-1 out of circulation while also understanding the enterprise impacts. Therefore, issuance that crosses the point in time eradication target today can occur and continue with no UI degradation in IE provided that the offending certificates are taken out of circulation by the point in time of policy violation. End of issuance at Microsoft is January 1, 2016. End of issuance at Google for 39 month certificates was October 1, 2013, with the effect of that issuance causing UI changes in Chrome in 8 weeks. Therefore, I think it is not correct to justify Google’s approach as the same as Microsoft’s.

      Somewhat further complicating matters, the February policy discussion from Google did not mention UI changes in November. Consistent interpretation of Google’s intent from CAs that participated in the discussion thread prior to the formal policy announcement shows that the perception was for Google to follow Microsoft’s plans. The escalation and immediacy of the recent action was anticipated by zero CAs as of February. This is why the consistent tone is that the action is sudden. Contrast this to the UI guidance given about CT and how far in advance CAs were given that guidance.

      • It seems I’ve unwittingly stumbled into a long-running controversy with the CAs on one side, and the browser developers on the other! I confess that my sympathies are with the browsers.

        Microsoft announced in November 2013 that they would not accept SHA-1 certificates for SSL from 2017 (and not for code signing from 2016). At this point, one might have expected a flurry of activity from the CAs, to start issuing SHA-256 certs immediately, make their customers aware that any multi-year SHA-1 certs would need to be reissued, etc. As far as I can tell, nothing actually happened. CAs continued to issue certificates *which they knew would have to be reissued*. (Or were they hoping that Microsoft would back down?)

        Speaking as the administrator of many SSL sites, I am very glad to start receiving gentle warnings, in plenty of time, about certificates that will need to be reissued. In my business, I have enough time to replace all the 2016/7-expiring SHA-1 certs before they start garnering warnings. Are you *really* suggesting that it would be better to have everything roll along without apparent problems…. till 2017-01-01 when it all breaks all at once?

        There seems to be wide dissension over whether Chrome’s plans were made sufficiently clear in the CA/Browser’s Forum back in February. I wasn’t there, and I’m not going to pass judgement. I do think it’s time to accept the reality: Chrome (with ~ 40% of the browser market) is doing this. It’s time to stop whining, and start fixing those certificates!

        • Jeremy

          “Microsoft announced in November 2013 that they would not accept SHA-1
          certificates for SSL from 2017 (and not for code signing from 2016). At
          this point, one might have expected a flurry of activity from the CAs,
          to start issuing SHA-256 certs immediately, make their customers aware
          that any multi-year SHA-1 certs would need to be reissued, etc. As far
          as I can tell, nothing actually happened. CAs continued to issue
          certificates *which they knew would have to be reissued*. (Or were they
          hoping that Microsoft would back down?)”

          There was a flurry of activity from a lot of CAs. Because you didn’t see it on the front-end simply means many of us agreed with the change and planned for it, changing the issuance process to require, or at least highly recommend, that all certs expiring after Jan 1 2017 be SHA-2.

  • Also, the analysis reposted in the Schneier article you link to, “lack of a practical attack until 2018”, includes this warning “the need to transition from SHA-1 for collision resistance functions is
    probably more urgent than this back-of-the-envelope analysis suggests.”

    And that analysis was made in 2012: pre-Snowden. If an organised crime syndicate can afford a practical SHA1 collision attack by 2018 *at the latest*, it is likely that a determined state actor can do so now.

  • Morgan Collett

    Notably absent from your SHA-256 support list are all feature phones. Symbian etc are so not dead yet. Millions of people in developing nations will go from somewhat less secure SSL to no access at all.

    • Steve Medin

      But Android solves that.

      • Morgan Collett

        Yes, but not fast enough. 40% of cellphones in South Africa are still feature phones, and in the rest of Africa, more than that. Devices are passed on to others when upgrading so it will take a while to kill them all.

        • Steve Medin

          Certainly Morgan, but perhaps less an issue for Google and its users? In fact, dare I say, … No, I’d better not.

        • Exactly what I’ve been saying. It’s just too soon, and not thoughtful or respectful. A smooth transition takes years, not months, and abusing a popular browser to annoy users, webdevs and admins worldwide with an opinion is not what google’s role should be. To compare this with MD5 is embarrassingly silly, it’s a completely different scale of security risk management for SHA-1. But OK, if Google wants us to become haters, they’re on the right track. I had already dumped chrome since their blocking of ad-blockers.

    • Users of such phones are, of course, entirely unaffected by what Chrome does; they were already doomed by Microsoft’s announcement in November 2013, and the even earlier decision (2011, I think) that SHA-1 certificates must go.
      Unfortunately, a two-track solution is not possible; only eradicating SHA-1 certificates from the Internet can solve the problem.

  • Tim Taylor

    The browser makers are the heroes here.

    If you, site operator, find yourself with consumers doubting the security of your site, don’t shake a fist at Google, but instead direct your ire to the CA which sold you an inferior product. A product whose “deprecation date” was in 2010 (U.S. government) and in 2011 (browser makers and, yes, the CAs).

    Instead of questioning why Google is giving users and site operators several months advance notice on action required by you to fix a looming problem, ask why the message had to come from a browser maker instead of from the vendor who sold you your certificate, most certainly with the claims that it was “state of the art”.

    Most CAs drug their heels, consistently and near unanimously pushing back the day when SHA-1 support would be removed, increasing the odds that its weakness would be exploited on the site you operate or the sites you use. Some still actively resist, suggesting we wait even longer, until the capability to exploit the weaknesses of SHA-1 are within reach of organized crime.

    When just a few months ago you found yourself reissuing certificates in response to the heartbleed bug, why didn’t you receive, or at least been given the advice to get, a state of the art SHA-256 signed certificate. Had they done that, not only would your site had been more secure, but you wouldn’t find yourself in the position of needing to reissue your certificate.

    • Jeremy

      “Most CAs drug their heels, consistently and near unanimously pushing back the day when SHA-1 support would be removed, increasing the odds that its weakness would
      be exploited on the site you operate or the sites you use. Some still
      actively resist, suggesting we wait even longer, until the capability to
      exploit the weaknesses of SHA-1 are within reach of organized crime.”

      This is silly. CAs aren’t affected whether you use SHA-1 or SHA-2, and most CAs have supported SHA-2 for a long time. No one that i know of is resisting the 2017 deadline. It’s the server operators trying to support the software driving continued use of SHA-1, not some weird demand by the CAs. It’s like blaming Google for people still using SSL3.0. Sure, they could turn it off but they don’t because of its impact on users…