
Gradually sunsetting SHA-1 - ivanr
http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html
======
ivanr
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-depre...](http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-
policy.aspx)

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

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

~~~
agl
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? :)

[1] [https://technet.microsoft.com/en-
us/library/security/2880823...](https://technet.microsoft.com/en-
us/library/security/2880823.aspx) [2]
[http://support.microsoft.com/kb/322389](http://support.microsoft.com/kb/322389)

~~~
eastdakota
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:

[https://www.cloudflare.com/apps/abetterbrowser](https://www.cloudflare.com/apps/abetterbrowser)

~~~
agl
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.)

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

~~~
ivanr
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...](http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile)

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

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

------
rdl
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
This was already announced by Microsoft last year:
[https://technet.microsoft.com/en-
us/library/security/2880823...](https://technet.microsoft.com/en-
us/library/security/2880823.aspx)

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.

~~~
flavmartins
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:

[http://www.darkreading.com/endpoint/authentication/digicert-...](http://www.darkreading.com/endpoint/authentication/digicert-
releases-tool-to-simplify-sha-2-migration-for-system-
administrators/d/d-id/1315841).

------
praseodym
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?

~~~
giovannibajo1
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
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.)

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

------
eridius
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
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-13...](http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf)
[http://news.netcraft.com/archives/2014/02/04/nist-
continues-...](http://news.netcraft.com/archives/2014/02/04/nist-continues-
using-sha-1-algorithm-after-banning-it.html)

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

~~~
Dylan16807
Heh, maybe they could extend it to self-signed being neutral...

~~~
JeremyBanks
I hope so, now that this has set the precedent.

------
higherpurpose
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
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)

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

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

~~~
v13inc
Why can't you just verify that the whole chain is SHA-1 instead of using the
expiration date as a heuristic?

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

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

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

~~~
scrollaway
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).

~~~
Alupis
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
Google is only available in the US.

------
timewasted
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)

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

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

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

~~~
derekerdmann
This is something Linus addressed quite a while ago:
[http://lwn.net/Articles/132513/](http://lwn.net/Articles/132513/)

~~~
eslaught
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_...](https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html)

------
soccerdave
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
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
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
your CA should offer you free re-issuing any time you want to regenerate it

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

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

~~~
gergles
Digicert, the CA that signs their cert, is all SHA1, so they'll probably need
to change CAs at a minimum.

~~~
iancarroll
Digicert offers SHA2 certificates. It's the default option IIRC. This only
applies to end entity certificates, mind you.

~~~
gergles
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
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#inte...](https://www.digicert.com/digicert-root-
certificates.htm#intermediates)

