They've actually split the deadlines for SSL Certificates and Code Signing client certificates.
The deadline for websites to upgrade their SSL Certificates is January 2017.
In January 2016, Microsoft will stop trusting code signed with a SHA1 certificate, unless it was timestamped prior to that date. In that case it will continue to be trusted until SHA1 is found be vulnerable to pre-image attack.
After reading that blog post from Microsoft, I believe even stronger now that Google is approaching this carelessly. Microsoft announced this almost a year ago and yet the blog post reads that they are giving until January 1st 2017 until they will stop accepting SHA-1 certs. Google announced this today and starting in 22 days they will be showing a Yellow Lock on my certificate just because the cert is set to expire AFTER January 1st, 2017. That is very different approaches!
Presumably the thinking is that certs shouldn't be issued with a validity more than a year or two. So certs expiring 2017 shouldn't be issued before 2015 or 2016… plenty of time for people to start issuing newer certs with stronger hashing. And if they don't… it's just a small visual warning, for now.
Other than not getting this started sooner, it seems fine to me.
I'm concerned that the net effect of this will be to make the Internet less secure. In most cases, webmasters will be forced to make a Faustian choice: live with the scary warning in Chrome for modern users or give up support of browsers running on Windows XP (pre-SP3) and early versions of Android (pre-2.3), since they don't support certificates with a more secure hash than SHA1. We'll likely write a blog post soon on how much of the Internet still uses these old browsers. It's a startling amount. While it's unlikely to be the parts of the web where Google generates a large amount of ad revenue (e.g., China), so perhaps they don't care, I am concerned the net effect will be a web that is actually less secure.
At CloudFlare, we have a plan to handle this gracefully for our customers (with both modern Chrome and old OSs) ahead of the change, but it's a non-trivial engineering challenge that many organizations won't make. I worry that, faced with the choice above, many organizations will simply opt not to support HTTPS at all. And, from my vantage point, that's a bigger risk to web security today than certificates signed with a SHA1 hash.
The world will be switching to SHA-256 - Microsoft already decided that last November [1]. This is just Chrome helping out.
Obviously, XP is a problem. We're planning on prompting Chrome users on affected versions to update, both at startup and on the error page. SP3 does exist and one doesn't need to pass the Genuine Windows check to install it[2] so I think we have a good chance to getting users to update once sites stop working. Even if you're going to serve different chains based on signature_algorithms, that gets you at most a year of extra time. Maybe you should be putting effort into getting people to SP3 instead? :)
While I'm a huge fan of what you're doing in terms of crypto at Google, it's hard for me to see this decision as anything other than reckless. I think we'll be able to show a number of empirical examples of how, over the coming months, it will make the web a less secure place as sites that we're just now starting to convince to adopt crypto will stop.
I do at least hope that you will make efforts to alert more of the general public of what's coming and how they can prepare ahead of time. While at CloudFlare we follow the crypto lists closely and know there have been discussions for some time, dropping this news quietly for general public consumption on the Google blog on a Friday afternoon was... an odd choice.
And, for the record, for the last two years we've made it one-click simple for any of the millions of sites on CloudFlare to alert their users to move off out-of-date browsers:
Unfortunately we don't have the technical ability, nor do people have the mental capacity, to cope with multiple URL schemes for different "levels" of security. SHA-1 limits the security for everyone and all uses. And if sites are worried about compat, Google will be doing this transition along with everyone else. That's a good tailwind to ride.
If Microsoft's 2016/2017 deadline is reckless, what SHA-1 deprecation date would be right by your measure? Some have suggested ~2020 (5 years issuance from 2015). Would you really be happy depending on SHA-1 in 2020?
(Edit: on re-read, the 2020 suggestion sounds like a strawman - but that's actually what we were on the road towards and we may not have even managed that.)
Google, CloudFlare and a handful of the technically sophisticated organizations have the ability to return different certificates depending on the connecting browser. Your argument would be far more persuasive if Google were really biting the bullet and dropping support for SHA1 even when an old browser connects. I assume that's not what you're doing, but please correct me if I'm wrong.
If you are returning two different certificates for two different situations at Google.com, the least you could do is dedicate some of your vast engineering resources to making the plugins to support such a setup production ready. If Google uses it's technical sophistication to avoid the pain while the rest of the web burns then that's, at best, hypocritical.
I'll make you this deal: if you do it for Apache, we'll do it for NGINX. That's the right thing to do. As would be making SSL certs free, but that's a conversation for another day.
Is it possible to specify both a RSA-SHA1 cert and a RSA-SHA256 cert that way, or would it have to be RSA-SHA1 and ECDH-SHA256?
Apache/OpenSSL would have to assume that pre-TLSv1.2 clients support only SHA1 because there's no signature_algorithms extension, but for TLSv1.2 clients can Apache/OpenSSL choose between a RSA-SHA1 cert and a RSA-SHA256 cert?
The reason I ask is because ECDH certs seem to be even harder to come by than RSA-SHA256 certs right now.
I haven't tried, but I think at the moment Apache supports only multiple certificates with different private key algorithms. Anything else would have to be implemented in custom code. IIRC, OpenSSL 1.0.2 (not yet released) has better support for multiple certificate chains on the same server.
Will www.google.com continue to be available over HTTP? If so, the old browsers will still be able to use Google search by simply avoiding HTTPS. That would lessen the impact on Google, in contrast to sites that follow best practice and unconditionally redirect HTTP to HTTPS.
You say that Google will be doing this transition along with everyone else, but you won't be feeling the same pain. Google's current cert expires November 24th, 2014, so when you extend it then it will be for 1 year and your new cert will expire before January 1st, 2016 which is pretty convenient for you because that cert (even if it is SHA-1) will still show up as a green bar through Chrome 41 so it will have no impact for you. I also second eastdakota's response that this was pretty crappy to drop as a Friday afternoon announcement.
(Google's certificates only last three months and that's not because of this announcement.)
The transition that I'm talking about is the transition to SHA-256 overall. If you're in a position where your CA sold you a certificate that they shouldn't have then I feel sorry, but if you're blaming us for that then I think you're pointing in the wrong direction.
I would guess that most buyers of certs are not technically sophisticated enough to know that they should have been looking for a cert with a specific encryption algo, especially if they bought a very long-lived cert x years ago. That said, I'm guessing that most reasonable cert providers will allow reissues.
What would be the technical challenges facing offering free wildcard certs? Is it just engineering time, or is there something more fundamental? That seems like it would do much more for web security than pushing for higher minimum encryption standards on certs would...
Incidentally, while easy to point a finger at Microsoft, note that Google itself shipped a crypto-nightmare of an operating system with Android for years. Pre-Android 2.3 phones remain a significant problem, especially in the developing world, and the upgrade path there isn't clear.
All XP users (including the zillions of pirated ones) can and should upgrade to SP3, free. That leaves aside the question of whether they should still be on the internet, sitting and waiting for the exploit which enables the next "Sapphire". That is going to be a fun day. I'll bring marshmallows.
The situation with Android, vendors, old versions, device abandonment and lack of security patches is terribly disappointing across the ecosystem. It does not have the same excuse of age that Windows XP does. I'm not sure how to remedy that, and I'm not even completely sure why it happened in the first place except for the melting pot of: carriers wanting complete images to test and to remain completely stable (big mistake: most software really needs security patches deployable globally within hours!); SoC vendors with closed-source binary blob drivers, and this being tolerated in the ecosystem (big mistake: this means when it's dead to the vendor it's dead to everyone, because ABI changes); and versions with high minimum memory requirements (which is improving recently, but I feel if you can't go back and run it on the ADP1, and it doesn't run worse than it ever did, you're still not really done with that yet). Projects like CyanogenMod at least help there.
I agree it is shocking how many are still out there, but given the choice between "HTTPS being secure" and "supporting insanely old/insecure software", choosing the latter seems like the kind of choice people will vividly remember when they come to regret it later.
> choice between "HTTPS being secure" and "supporting insanely old/insecure software",
I think there are really three outcomes:
1. HTTPS is widely used, it's secure, insanely old/insecure software is not supported. (Ideal outcome)
2. HTTPS is widely used, but using SHA1 certs for a little longer so that insanely old/insecure software is supported.
3. HTTPS is less widely used, but is secure with SHA2 certs, and insanely old/insecure software is still supported.
My concern (and Matthew's too I think) is that the aggressive deprecation of SHA1 will put us on a trajectory to outcome 3. We're at a unique point in history right now: there is incredible momentum behind converting sites to HTTPS, even sites that traditionally would not have used HTTPS (such as all static sites). The SHA1 deprecation might throw a wrench into this and cause site operators to reconsider switching to HTTPS. If not for this momentum, I'd agree that aggressively deprecating SHA1 would be the clearly correct course of action, but at this moment in history I'm deeply ambivalent. Disrupting the HTTPS momentum would be very sad, especially since switching to HTTPS provides an immediate defense against mass passive eavesdropping.
Not responding directly to your point (that this might make the Internet less secure), but there is also another approach -- deploying with two certificates. You can have a RSA/SHA1 certificate for older software and an ECDSA/SHA256 certificate for modern user agents. That should keep everyone happy. I dare say that, with some effort, it might even be possible to have a RSA/SHA1 and RSA/SHA256 certificate combination for the same host.
Of course, doing that is a lot of work. But at least your company is in a position to do the work once and automate it afterwards for all your customers.
Yes, that's what we're doing at CloudFlare. However, the patches to do it in major web server platforms are best characterized as "experimental" -- which is spooky for organizations to deploy into production environments. (We plan on open sourcing any work we do to improve them.) But, given how hard it is for most web admins to even manage one certificate, configuring a server to correctly manage two is... daunting. As you suggest, this change is undoubtedly good for our business, but I think it's bad for the web.
Although I'm an AGL fanboy (I have his rookie card) I have to agree with Matthew here. Pushing the transition this fast, just when the world is on the verge of accepting HTTPS as the default, is reckless and will overall reduce the safety of the Internet.
FYI, we are deploying in the same manner as Cloudflare, with RSA/SHA1 and ECDSA/SHA256 side-by-side. We are committing our changes to the public ATS repository and hopefully those changes are useful to other projects. Unfortunately this is dependent on OpenSSL 1.0.2, so we might have to deploy beta code into production if the OpenSSL project can't beat Chrome's arbitrary deadline.
This enables SHA-2 certificates. Deployment of the patch is another problem, since it's a HotFix (which may have enterprise-QA issues) and not intended for general use, AFAIK. Still, I've been using it since WS2008 originally came out.
The hotfix KB 968730 for Server 2003 includes updates from hotfix KB 938397. An important thing to note from KB 938397 is that "KB 938397 will bring Windows Server 2003 to the same level of functionality as Windows XP with Service Pack 3." [1]
What that translates to is that it only gives Server 2003 SHA2 support as a client, not as a server. I.e. You can connect to sites that are using SHA2 certs, but you cannot bind a SHA2 cert to your own website in IIS 6/Server 2003.
So once SHA1 is completely deprecated, those hosting sites or legacy apps on Windows Server 2003 will not be able to upgrade to SHA2 certs.
Luckily, MS stripped the GDR branch from all XP/Server 2003 patches one year before XP went out of support, and https://support.microsoft.com/kb/2868626 was released after that was done.
It's a startling amount today. Just by virtue of making the announcement, Google knocks that number down quite a bit.
Honestly, in a world where your choices are "doesn't work" and "secure", and there is no in between "works but isn't secure", security becomes a LOT simpler.
I'm extremely troubled that CloudFlare is taking this short-sighted stance.
The faustian choice will soon be between having no security on any platform and supporting ancient platforms. This could come at any time. It could already be too late.
Like it or not, you are a security company. You should act like it. This is not acting like it.
I'm glad to see people move off old browsers, in general. SHA1 is far from the biggest problem with Windows XP SP2; in fact, I'd probably say SHA1 is one of the most secure aspects of the OS. The actual weaknesses in SHA1 which have been identified are very serious, but still requiring on the order of 2^61 operations to cause a collision, and there is a fairly indirect path between hash collision and end of the world for many protocols.
The problem I have is how Google is doing this. There was a pretty clearly announced date. Google used a random browser meeting's minutes to make what is essentially a major policy change, and then assumed CAs would notify their customers.
The victims here are end users and site operators; CAs benefit because people buy new certs (and at worst, it's customers who have already bought something which breaks...). There was no real incentive for CAs to communicate with sites, and they're not really known as responsive businesses anyway.
Doing this with effect during the holiday season is kind of the definition of dick move. Pushing it out 6 mo wouldn't have appreciably hurt the SHA1 migration efforts, but would have dramatically reduced pain for end users and site admins. Providing direct notice to the world (such as this blog post), so users and site admins would actually see it, is how notice should be given; not an obscure forum or relying on CAs with no business interest.
Unfortunately, many CAs decided to ignore it, presumably on the assumption that Microsoft would be forced to back down. We've done this dance with MD5 and 1024-bit certificates and we know how it goes. Here's a quick list of CAs that issued more than 2000 certificates extending into 2017 with SHA-1:
We would all have liked CAs to have acted either when the Baseline was updated (2011) or when Microsoft laid down dates (Nov 2013) or when Chrome talked about doing this at the CA/B Forum meeting earlier this year. It is unfortunate that that 2016/2017 dates are being ignored.
If you run a site and want to be insulated from this sort you might want to consider getting one year certificates. CAs like to sell multiple years of course but doing renewal once every three (or more) years means that you have a significant risk of loosing the institutional knowledge of how to do it. (E.g. the renewal remainder email goes to someone who left last year and you then have a panic when it expires). Additionally, very long lived certificates are not insulated from from these sorts of changes and you may need to replace them during their lifetime anyway.
The claim that CAs have been sitting on SHA-1 and not migrating to SHA-2 is not entirely accurate, at least in my experience with DigiCert.
Consequently, people I know there have told me that 25% of all SHA-2 certs expiring in 2017 have been issued by DigiCert, well beyond their market share. DigiCert has migrated all but a couple hundred customer certificates expiring in 2017 onto SHA-2, and those should be moved soon.
As for CAs in general, much of the blame lies not with CAs but with the lack of SHA-2 compatibility in certain devices and software.
For its part, today, DigiCert released a new, free tool that makes it easy for sys admins to identify all SHA-1 certs in their networks, determine validity periods and how future Chrome releases will treat these certs, and help admins map out a path toward SHA-1 sunsetting and SHA-2 migration.
DigiCert will also replace any SHA-1 certs – for current customers and non-customers alike – for free. They will match the existing SHA-1 term for a free upgrade to SHA-2 through the end of the licensing period. Here’s a link from a Dark Reading article:
I suppose the CA's didn't jump on issuing SHA2 certs the same day as the as the Baseline update or the MS announcement, but they don't seem to be standing still.
Wondering how many of those certs from GlobalSign, GoDaddy, GeoTrust, etc. are 4 & 5 year certs purchased prior to any announcement? As you noted CA's like to push multi-year certs.
While you can usually reissue/re-key your cert free of charge with CA's, a lot of companies are probably hesitant to make sudden moves to SHA2 when there are compatibility concerns. Many on legacy systems like Server 2003 cannot update to SHA2. As I mentioned in another comment the hotfixes only bring Server 2003 SHA2 support up to the same level as XP SP3. (Only compatible as a client, not as a server).
Also Microsoft's fastest approaching SHA2 deadline is January 2016 for CodeSigning yet Windows Vista & 7 don't support SHA2 signatures on kernel drivers. Not sure if that's been patched yet, but it would seem Microsoft isn't fully prepared to support their own policies either at the time of their own announcement.
Google acting like they control the whole Internet and that everyone will yield to their power is nothing new; sadly, in some ways that is probably true.
It's probably true, but they honestly largely use this power responsibly. I don't even really have a problem with the action here, just the timing and means of announcement.
I think it's really crazy that certificates are now declared insecure based on their expiration date. We've deployed several certificates with a three year validity (i.e. valid after 1-Jan-2017), and since our CA could only provide SHA-1, that's what we're using. Now these certificates get marked as insecure. However, if we'd gone for a 2 year validity, we'd be fine until somewhere in 2016.
How does this help security? Why not have us replace these SHA-1 certificates somewhere in 2016?
Because an attacker could get a copy of your certificate now, begin looking for a sha1 collision, and ride the Moore law until 2017; at any time they find a collision, they can begin MITM-ing your users. Have a look at the numbers linked in OP for an idea of the cost that is required to collide SHA1; news at 5pm: it's well within NSA wallet, and goes down and down very fast.
So, deprecating a certificate on the basis of the issue date is a decision that makes to force people to start caring of the whole problem at the certain date, but then you would have people getting a 5 year SHA1 the day before the cutoff. Deprecating on the expiration date is the decision that better models the security risks.
No they couldn't, because attacking a site's existing certificate in that way would require a preimage attack for SHA-1 which is much harder to achieve than a collision and unlikely to be feasable in the near future. In order to achieve a collision the attacker needs to control the contents of both certificates, which means they have to do all the computation and then somehow get a CA to issue a certificate with the exact contents they need. (This shouldn't be possible - after the MD5 attack a few years ago, CAs are expected to to take countermeasures to ensure an attacker doesn't have this level of control.)
You have to draw a line in the sand somewhere... And as mentioned elsewhere, you could keep using your SHA-1 certificate for older user agents while serving modern platforms a new, SHA-256 certificate in your name. Dropping SHA-1 in 2015 is better than doing so in 2016, after all. ;-)
As someone who cares about security, thanks Google!
As someone who administers some servers that are affected by this, I'm annoyed, because I now have a new project that has to be done within the next 6 months.
I notice there's no mention of what should be used instead. I'm sure that it's obvious to a lot of people, but not to me. Are we supposed to use SHA-2? SHA-3? Or something else?
Also, does Google believe that we should stop using SHA-1 for other things too, or is this only an issue with really high-profile, high-reward targets like certificates?
The problem i have with their "neutral, lacking security" icon is that it does not indicate that anything is wrong when in fact there is. https:// should never have a neutral icon. it should be VALID or INVALID.
Mozilla and IE should adopt similar policies, and not just for SHA1 deprecation, but for other weak security protocols, too. If website A uses much weaker security than website B, they shouldn't be treated equally by the browser.
Reward the ones who embrace stronger security, punish (within reason, and gradually) those who don't.
Firefox Bug 942515 - stop accepting SHA-1-based SSL certificates with notBefore >= 2014-03-01 and notAfter >= 2017-01-01, or any SHA-1-based SSL certificates after 2017-01-01
This deprecation policy appears to affect some (possibly all) Startcom SSL certificates, which are chained through "StartCom Class 1 Primary Intermediate Server CA", which is signed with SHA1 and expires on 2017-10-24.
It specifically says the dates apply to the end entity. They're not trying to get people off SHA1 in a couple months, they're trying to get them off in a year or two.
Just to clarify: the other replies are correct. The logic is that if the leaf certificate has an expiry after Dec 31st, 2015 then the whole chain must be SHA-256. If the leaf expires before that, then other certificates in the chain don't matter.
If you have a one year certificate (and I always recommend getting one year certificates so that these issues don't affect you and so that renewal becomes an annual chore, not an irregular panic) then you don't have to worry.
StartSSL simply need to cut new intermediates, signed with SHA-256, and provide them to customers once the leaf certificates that they issue start to stretch into 2016.
Because then everything will seem fine until 2017 at which point all the sites break at once. Using the expiration date makes it gradual and shows problems when certificate updates are tested.
Turns out there is already a class 1 SHA-2 intermediate! It's just buried on their site, but you can add it to your chain and it passes SSLLabs validation and otherwise looks totally fine. So this isn't as huge a problem as I had thought.
It also says "[...] which include a SHA-1-based signature as part of the certificate chain". In other words, SHA1 is deprecated in the entire chain (minus the root, where the signature is irrelevant).
The root could be SHA1 valid until 2050 and it wouldn't matter. Your bog-standard certificate is valid for one year, and you don't have to care until you're renewing.
Yes, this is going to further insecure the Internet by forcing people back to the for-pay CAs, unless Startcom manages to fix it basically instantly and forces everyone to get new certs, very very quickly.
As I understood it any certificate in the chain (except the root) is considered. Validity is usually longer for intermediate certificates [such as the Starcom intermediary, quoted above].
This is about to become a massive issue for Godaddy SSL users[1] seeing that Godaddy has still not added their G2 CA server (which signs all SHA-2 certs at Godaddy) to the default truststore for Java and some other devices/languages/platforms!
Excellent; this should be another reason for some people to no longer be a client of one of the worst companies in the tech sector today.
I'll leave CA recommendations to those who deal with them more than I, but if you use Godaddy as a registrar I would urge you to switch to Gandi.net (or namecheap.com if you cannot afford Gandi).
Google is a decent registrar now that I've moved some domains to them... although I don't know if they offer SSL yet directly, I think they recommend a few 3rd parties though.
mappu no, G2 is it's own root, but there are ways to get it to work -- but it's rather impractical for deployed applications to public users, etc. They expect it to "just work". So, as the post mentions... the current only work-around is to get a SHA-1 cert from Godaddy's Class 2 CA server (which sings all SHA-1 certs).
I really think people need to dog on Godaddy more about this. It's not really excusable to be a half-assed CA today...
I had previously written a simple program to check the expiration dates of SSL certs, and warn if the date is approaching. After reading this (and the Microsoft article), I updated it to check signature algorithms as well. If anyone is interested in such a program: https://github.com/timewasted/go-check-certs
This leads to me to think about the longer term viability of bitcoin. Bitcoin uses a combination of RIPEMD and SHA256. Given the sha-2 family was released in 2001, when is SHA-2 going to go into depreciation cycle and what does that mean for the bitcoin network.
Given that there are plenty of op-codes left, the network can probably easily start switching into in the next generation of hashing algorithms.
This is the beautiful thing about open networks, it evolves organically. Whereas you can't say the same about bank protocols.
You can't look at SHA-1, SHA-2, and SHA-3 as successive "versions" of hash functions. They're distinct things. SHA-3 isn't so much "better" than SHA-2 as it is "different". It has some practical improvements, but those improvements aren't relevant to the certificate use case.
So far as we know, there is no timeline for the deprecation of SHA-2. In fact, most people are better off right now using SHA-2 than SHA-3.
Anyone who has dealt with bank protocols will tell you that "organic" is certainly an apt, if perhaps too kind, word. It's not like it's all designed by committee.
The difference is you don't get to see the haggling and back and forth. Ten years from now, when a large bitcoin institution has a mission-critical legacy app that depends on some facet of the network, we're likely to see similar shenanigans.
I would venture, at least. Simplicity is probably the product of a) abstraction, or b) a small number of stakeholders.
Does this mean anything for Git and other VCSs, which uses SHA1 for identifying commits and other blobs? For non-malicious content, you won't care, but if collision attacks are actually feasible, then Git's security guarantees ("you can fetch from anywhere") might potentially be compromised.
The critical question is "how broken is SHA1?" Linus essentially bets on it being not broken, or at least, the same degree of broken as the alternatives. At the time that was a reasonable argument. But the numbers quoted in the article [1] seem to point to SHA1 collision attacks being practical within 10 years, and that's based purely on expected hardware advances and not on special hardware acceleration or theoretical breakthroughs.
So I ask again: do we need to revisit this? Just because Linus was dismissive 9 years ago doesn't mean we should ignore the possibility.
Anybody know what the easiest way to determine if your certificate is affected? I looked at my certificate and it says Signature Algorithm is "SHA-1 with RSA Encryption". Is this affected? When I viewed the certificate for google.com it also said "SHA-1 with RSA Encryption".
Yes. Both those certificates are affected. If I had to guess, Google will begin issuing a non-SHA1 cert to modern browser users and a SHA1 certificate to older browsers before the end of September. I wish I could give you easy advice on how to do that yourself.
Thanks for the reply, I thought I was understanding it correctly. Now that I think about it more, they will still be able to use SHA-1 and not be affected because they will surely just issue another certificate that only lasts 1 year which means it will expire before January 2016, so it will still show up as Green in Chrome. Sucks for me because we paid for a cert through July 2017 and now we'll probably have to pay more money to get a non-SHA1 cert.
I feel a bit uneasy with having the "unsafe" when SHA1 is technically still safe - just not as safe as, say, sha256 (which is itself probably not as safe as sha512, etc.). It would be nice to have a better "marker" for it instead of having a very fast deprecation rate.
The linked article to Schneier's blog shows that practical attacks can be afforded as soon as 2018. It's absolutely not safe anymore, at least for that usage.
It doesn't, it applies to the entire cert chain (minus the root). DigiCert's non-EV intermediate cert (DigiCert Secure Server CA) is SHA1, so until they fix that, all DigiCert users are still going to be affected.
