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? :)
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
[+] [-] ivanr|11 years ago|reply
[+] [-] eastdakota|11 years ago|reply
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.
[+] [-] agl|11 years ago|reply
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? :)
[1] https://technet.microsoft.com/en-us/library/security/2880823... [2] http://support.microsoft.com/kb/322389
[+] [-] AlyssaRowan|11 years ago|reply
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.
[+] [-] ivanr|11 years ago|reply
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.
[+] [-] hstrauss|11 years ago|reply
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.
[+] [-] cbsmith|11 years ago|reply
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.
[+] [-] nknighthb|11 years ago|reply
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.
[+] [-] serge2k|11 years ago|reply
At some point support should be dropped.
[+] [-] rdl|11 years ago|reply
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.
[+] [-] agl|11 years ago|reply
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:
GlobalSign nv-sa: 75,312 GoDaddy: 41,606 GeoTrust: 40,429 Comodo: 37,789 Verisign: 34,927 Terena: 9,444 Thawte: 8,735 Internet2: 8,637 Network Solutions: 8,077 Entrust: 5,542 AlphaSSL: 3,458
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.
[+] [-] userbinator|11 years ago|reply
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.
[+] [-] praseodym|11 years ago|reply
How does this help security? Why not have us replace these SHA-1 certificates somewhere in 2016?
[+] [-] giovannibajo1|11 years ago|reply
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.
[+] [-] lstamour|11 years ago|reply
[+] [-] mqatrombone|11 years ago|reply
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.
[+] [-] eridius|11 years ago|reply
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?
[+] [-] robertduncan|11 years ago|reply
SHA-1 has been deprecated for a while but is still in (very) widespread use, see: http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-13... http://news.netcraft.com/archives/2014/02/04/nist-continues-...
[+] [-] zhng|11 years ago|reply
[+] [-] Dylan16807|11 years ago|reply
[+] [-] sp332|11 years ago|reply
[+] [-] bgentry|11 years ago|reply
[+] [-] higherpurpose|11 years ago|reply
Reward the ones who embrace stronger security, punish (within reason, and gradually) those who don't.
[+] [-] cpeterso|11 years ago|reply
https://bugzil.la/942515
[+] [-] duskwuff|11 years ago|reply
[+] [-] Dylan16807|11 years ago|reply
[+] [-] gergles|11 years ago|reply
[+] [-] corford|11 years ago|reply
tl;dr They will re-issue SHA-2 versions of your certs for free.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] matchu|11 years ago|reply
[+] [-] Alupis|11 years ago|reply
[1] http://stackoverflow.com/questions/18746565/godaddy-ssl-cert...
[+] [-] timewasted|11 years ago|reply
[+] [-] jimmyfalcon|11 years ago|reply
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.
[+] [-] eslaught|11 years ago|reply
[+] [-] derekerdmann|11 years ago|reply
[+] [-] soccerdave|11 years ago|reply
[+] [-] eastdakota|11 years ago|reply
[+] [-] zobzu|11 years ago|reply
[+] [-] rakoo|11 years ago|reply
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.
[+] [-] fryguy|11 years ago|reply
[+] [-] yuhong|11 years ago|reply