Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gradually sunsetting SHA-1

googleonlinesecurity.blogspot.com

Post reply on HN
Print view View original

81–90 of 100 posts

Re: Gradually sunsetting SHA-1

#81

Post by gergles »

Dylan16807 wrote: post #18
duskwuff wrote: post #13

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.

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.

https://www.startssl.com/certs/class1/sha2/pem/sub.class1.se...

Re: Gradually sunsetting SHA-1

#82

Post by agwa »

ivanr wrote: post #67
eastdakota wrote: post #62

Earlier quoted context omitted.

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 diffe…

Actually, Apache already supports deployments with more than one certificate for the same host: http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertifi...

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.

Re: Gradually sunsetting SHA-1

#83

Post by secalex »

eastdakota wrote: post #35
ivanr wrote: post #31

Earlier quoted context omitted.

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…

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

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.

Re: Gradually sunsetting SHA-1

#84

Post by agwa »

AlyssaRowan wrote: post #70
eastdakota wrote: post #29

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…

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 disappointi…

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

Re: Gradually sunsetting SHA-1

#85

Post by Alupis »

mappu wrote: post #46
Alupis wrote: post #15

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

If the G2 CA is signed by their other CAs which are in the trust root, you can just add it to the chain you're serving, right?

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

Re: Gradually sunsetting SHA-1

#86

Post by Alupis »

scrollaway wrote: post #41
Alupis wrote: post #15

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

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.

Re: Gradually sunsetting SHA-1

#87

Post by agwa »

agl wrote: post #74
eastdakota wrote: post #62

Earlier quoted context omitted.

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 diffe…

> 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. That's certainly the plan. What did I say that suggests otherwise?

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.

Re: Gradually sunsetting SHA-1

#88

Post by ivanr »

agwa wrote: post #82
ivanr wrote: post #67

Earlier quoted context omitted.

Actually, Apache already supports deployments with more than one certificate for the same host: http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertifi...

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…

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.

Re: Gradually sunsetting SHA-1

#89

Post by eslaught »

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.

Re: Gradually sunsetting SHA-1

#90

Post by derekerdmann »

eslaught wrote: post #89

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.

This is something Linus addressed quite a while ago: http://lwn.net/Articles/132513/
Post reply on HN