14 ms·

Gradually sunsetting SHA-1

146 points by ivanr 12y ago

deleted 12y ago
[deleted]
- matchu 12y ago
  It's not a typo in British English! :)
higherpurpose 12y ago
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.
- cpeterso 12y ago
  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 https://bugzil.la/942515 https://bugzil.la/942515
zhng 12y ago
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:// https:// should never have a neutral icon. it should be VALID or INVALID.
- sp332 12y ago
  There's nothing wrong with a valid SHA-1 certificate.
- Dylan16807 12y ago
  Heh, maybe they could extend it to self-signed being neutral...
  - JeremyBanks 12y ago
    I hope so, now that this has set the precedent.
- bgentry 12y ago
  At some point in the not-too-distant future, anything other than full 100% verified HTTPS should have a red "danger" icon.
eridius 12y ago
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?
- robertduncan 12y ago
  SHA-2 for new certificates. 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-131A.pdf http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-13... http://news.netcraft.com/archives/2014/02/04/nist-continues-using-sha-1-algorithm-after-banning-it.html http://news.netcraft.com/archives/2014/02/04/nist-continues-...
jimmyfalcon 12y ago
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.
- phillmv 12y ago
  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.
- imaginenore 12y ago
  It's a common myth. Bitcoin can be easily upgraded to use any algorithm. https://en.bitcoin.it/wiki/Myths#Quantum_computers_would_break_Bitcoin.27s_security https://en.bitcoin.it/wiki/Myths#Quantum_computers_would_bre... https://en.bitcoin.it/wiki/Myths#Bitcoins_are_worthless_because_they.27re_based_on_unproven_cryptography https://en.bitcoin.it/wiki/Myths#Bitcoins_are_worthless_beca...
- tptacek 12y ago
  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.
ivanr 12y ago
By the way, this blog post does not mention that Microsoft already effectively killed SHA1 last year when it announced that it wouldn't accept SHA1 certificates after 2016: http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-depre...
- soccerdave 12y ago
  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!
  - paulannesley 12y ago
    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.
    - spicyj 12y ago
      > small visual warning The post says that in Chrome 41 (Q1 2015) the https will display in red with a strikethrough, which is more than a small visual warning.
- Gregordinary 12y ago
  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.
yuhong 12y ago
One of the affected sites will be LinkedIn. I think they tried SHA256 once before reverting to SHA1.
- gergles 12y ago
  Digicert, the CA that signs their cert, is all SHA1, so they'll probably need to change CAs at a minimum.
  - iancarroll 12y ago
    Digicert offers SHA2 certificates. It's the default option IIRC. This only applies to end entity certificates, mind you.
    - gergles 12y ago
      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.
      - iancarroll 12y ago
        I missed the mention about the chain, sorry. They do operate an SHA256 intermediary, "DigiCert SHA2 Secure Server CA". They also operate "DigiCert SHA2 Extended Validation Server CA". Both are documented here: https://www.digicert.com/digicert-root-certificates.htm#intermediates https://www.digicert.com/digicert-root-certificates.htm#inte...
duskwuff 12y ago
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.
- Dylan16807 12y ago
  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.
  - gergles 12y ago
    > and which include a SHA-1-based signature as part of the certificate chain
  - ivanr 12y ago
    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).
    - Dylan16807 12y ago
      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.
  - agl 12y ago
    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.
zobzu 12y ago
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.
- rakoo 12y ago
  > SHA1 is technically still safe 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 12y ago
  Many uses for hashing algorithms don't care about collision resistance (HMAC/passwords). Signatures/Certificates are not one of those things.
Alupis 12y ago
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! [1] http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java http://stackoverflow.com/questions/18746565/godaddy-ssl-cert...
- scrollaway 12y ago
  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).
  - sandstrom 12y ago
    I second this. It's an excellent reason to switch away from GoDaddy! gandi.net, namecheap.com are both good alternatives.
  - robertduncan 12y ago
    Note that Gandi do not offer SHA-2 certificates at all at the moment. https://twitter.com/gandibar/status/508001036653826049 https://twitter.com/gandibar/status/508001036653826049
  - Alupis 12y ago
    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.
    - scrollaway 12y ago
      Google is only available in the US.
- mappu 12y ago
mqatrombone 12y ago
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.
eastdakota 12y ago
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.
- ivanr 12y ago
  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.
  - eastdakota 12y ago
    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.
rdl 12y ago
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.
- agl 12y ago
  This was already announced by Microsoft last year: https://technet.microsoft.com/en-us/library/security/2880823.aspx https://technet.microsoft.com/en-us/library/security/2880823... 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.
praseodym 12y ago
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?
- lstamour 12y ago
  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. ;-)
- giovannibajo1 12y ago
  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.
  - makomk 12y ago
    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.)
soccerdave 12y ago
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".
- eastdakota 12y ago
  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.
  - soccerdave 12y ago
    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.
    - rstupek 12y ago
      your CA should offer you free re-issuing any time you want to regenerate it
  - tbrownaw 12y ago
    How? I would expect anything that might identify the browser would be sent after the encryption was set up?
    - bzbarsky 12y ago
      The list of supported cyphersuites is sent before the encryption is set up. Though some browsers lie in that list and list things they don't actually support, of course...
corford 12y ago
If anyone uses comodo certs, they have a page up explaining how this change affects you: http://www.comodo.com/e-commerce/SHA-2-transition.php http://www.comodo.com/e-commerce/SHA-2-transition.php tl;dr They will re-issue SHA-2 versions of your certs for free.
timewasted 12y ago
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 https://github.com/timewasted/go-check-certs
eslaught 12y ago
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.
- derekerdmann 12y ago
  This is something Linus addressed quite a while ago: http://lwn.net/Articles/132513/ http://lwn.net/Articles/132513/
  - eslaught 12y ago
    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. [1]: https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html https://www.schneier.com/blog/archives/2012/10/when_will_we_...

146 points by ivanr 12y ago

deleted 12y ago

[deleted]

matchu 12y ago
It's not a typo in British English! :)

higherpurpose 12y ago

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.

cpeterso 12y ago
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 https://bugzil.la/942515 https://bugzil.la/942515

zhng 12y ago

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:// https:// should never have a neutral icon. it should be VALID or INVALID.

sp332 12y ago
There's nothing wrong with a valid SHA-1 certificate.
Dylan16807 12y ago
Heh, maybe they could extend it to self-signed being neutral...
- JeremyBanks 12y ago
  I hope so, now that this has set the precedent.
bgentry 12y ago
At some point in the not-too-distant future, anything other than full 100% verified HTTPS should have a red "danger" icon.

eridius 12y ago

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?

robertduncan 12y ago
SHA-2 for new certificates. 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-131A.pdf http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-13... http://news.netcraft.com/archives/2014/02/04/nist-continues-using-sha-1-algorithm-after-banning-it.html http://news.netcraft.com/archives/2014/02/04/nist-continues-...

jimmyfalcon 12y ago

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.

phillmv 12y ago
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.
imaginenore 12y ago
It's a common myth. Bitcoin can be easily upgraded to use any algorithm. https://en.bitcoin.it/wiki/Myths#Quantum_computers_would_break_Bitcoin.27s_security https://en.bitcoin.it/wiki/Myths#Quantum_computers_would_bre... https://en.bitcoin.it/wiki/Myths#Bitcoins_are_worthless_because_they.27re_based_on_unproven_cryptography https://en.bitcoin.it/wiki/Myths#Bitcoins_are_worthless_beca...
tptacek 12y ago
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.

ivanr 12y ago

By the way, this blog post does not mention that Microsoft already effectively killed SHA1 last year when it announced that it wouldn't accept SHA1 certificates after 2016: http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-depre...

soccerdave 12y ago
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!
- paulannesley 12y ago
  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.
  - spicyj 12y ago
    > small visual warning The post says that in Chrome 41 (Q1 2015) the https will display in red with a strikethrough, which is more than a small visual warning.
Gregordinary 12y ago
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.

yuhong 12y ago

One of the affected sites will be LinkedIn. I think they tried SHA256 once before reverting to SHA1.

gergles 12y ago
Digicert, the CA that signs their cert, is all SHA1, so they'll probably need to change CAs at a minimum.
- iancarroll 12y ago
  Digicert offers SHA2 certificates. It's the default option IIRC. This only applies to end entity certificates, mind you.
  - gergles 12y ago
    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.
    - iancarroll 12y ago
      I missed the mention about the chain, sorry. They do operate an SHA256 intermediary, "DigiCert SHA2 Secure Server CA". They also operate "DigiCert SHA2 Extended Validation Server CA". Both are documented here: https://www.digicert.com/digicert-root-certificates.htm#intermediates https://www.digicert.com/digicert-root-certificates.htm#inte...

duskwuff 12y ago

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.

Dylan16807 12y ago
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.
- gergles 12y ago
  > and which include a SHA-1-based signature as part of the certificate chain
- ivanr 12y ago
  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).
  - Dylan16807 12y ago
    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.
- agl 12y ago
  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.

zobzu 12y ago

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.

rakoo 12y ago
> SHA1 is technically still safe 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 12y ago
Many uses for hashing algorithms don't care about collision resistance (HMAC/passwords). Signatures/Certificates are not one of those things.

Alupis 12y ago

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! [1] http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java http://stackoverflow.com/questions/18746565/godaddy-ssl-cert...

scrollaway 12y ago
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).
- sandstrom 12y ago
  I second this. It's an excellent reason to switch away from GoDaddy! gandi.net, namecheap.com are both good alternatives.
- robertduncan 12y ago
  Note that Gandi do not offer SHA-2 certificates at all at the moment. https://twitter.com/gandibar/status/508001036653826049 https://twitter.com/gandibar/status/508001036653826049
- Alupis 12y ago
  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.
  - scrollaway 12y ago
    Google is only available in the US.
mappu 12y ago

mqatrombone 12y ago

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.

eastdakota 12y ago

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.

ivanr 12y ago
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.
- eastdakota 12y ago
  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.

rdl 12y ago

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.

agl 12y ago
This was already announced by Microsoft last year: https://technet.microsoft.com/en-us/library/security/2880823.aspx https://technet.microsoft.com/en-us/library/security/2880823... 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.

praseodym 12y ago

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?

lstamour 12y ago
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. ;-)
giovannibajo1 12y ago
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.
- makomk 12y ago
  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.)

soccerdave 12y ago

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".

eastdakota 12y ago
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.
- soccerdave 12y ago
  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.
  - rstupek 12y ago
    your CA should offer you free re-issuing any time you want to regenerate it
- tbrownaw 12y ago
  How? I would expect anything that might identify the browser would be sent after the encryption was set up?
  - bzbarsky 12y ago
    The list of supported cyphersuites is sent before the encryption is set up. Though some browsers lie in that list and list things they don't actually support, of course...

corford 12y ago

If anyone uses comodo certs, they have a page up explaining how this change affects you: http://www.comodo.com/e-commerce/SHA-2-transition.php http://www.comodo.com/e-commerce/SHA-2-transition.php tl;dr They will re-issue SHA-2 versions of your certs for free.

timewasted 12y ago

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 https://github.com/timewasted/go-check-certs

eslaught 12y ago

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.

derekerdmann 12y ago
This is something Linus addressed quite a while ago: http://lwn.net/Articles/132513/ http://lwn.net/Articles/132513/
- eslaught 12y ago
  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. [1]: https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html https://www.schneier.com/blog/archives/2012/10/when_will_we_...