Why Google is Hurrying the Web to Kill SHA-1

Two nits, both pedantic:<p>An attack on SHA1 that makes certificate forgery viable within the next few years doesn&#x27;t seem very likely, although over the long term it might be. The attack on SHA1 isn&#x27;t like the attacks on RSA-1024; my sense is that the literature already knows how to break RSA-1024 given enough compute, but does not know how to do that with SHA1. Further, factoring RSA-1024 provides an attacker with a total break of RSA-1024 TLS, but not every attack on SHA1 will necessarily do the same.<p>Second, there&#x27;s a subtext that SHA-3 having been standardized somehow puts the writing on the wall (albeit, a far-away wall) for SHA-2. Not so; SHA-2 could remain secure (in its TLS certificate use case) indefinitely.

A while back I launched a SSL scanner [1] and got tons of feedback from people at Facebook, Google, Microsoft.<p>The most divisive item was how to represent SHA1 deprecation. The OPs article doesn&#x27;t really touch on it, but the reason that Google and everyone else haven&#x27;t moved on is that there still exist a sizeable number of clients that can only accept SHA1 (and will error on anything else).<p>I actually suspect that large sites like Facebook, etc will maintain multiple certs at the different levels and dynamically serve the best one up that the client can support. They&#x27;re already doing things like only serving HSTS to browsers that identify as Chrome, etc.<p>1 - <a href="https://www.expeditedssl.com/simple-ssl-scanner/scan?target_domain=google.com" rel="nofollow">https:&#x2F;&#x2F;www.expeditedssl.com&#x2F;simple-ssl-scanner&#x2F;scan?target_...</a>

I&#x27;d like to see them gradually downgrade all non-PFS connections. Non-PFS connections should be considered medium-to-highly vulnerable, and shouldn&#x27;t receive a green icon in browsers.<p>Unfortunately, they&#x27;ve just recommended everyone to use &quot;2048-bit keys&quot; when they announced the HTTPS Google ranking policy. A lot of developers won&#x27;t understand the difference between a 2048-bit RSA key and a 256-bit ECC key, so they&#x27;ll just pick RSA, since &quot;Google said 2048-bit keys!&quot;. Sooo...maybe this policy will come in 10 years.<p><a href="http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html" rel="nofollow">http:&#x2F;&#x2F;googlewebmastercentral.blogspot.com&#x2F;2014&#x2F;08&#x2F;https-as-...</a>

Everyone is vulnerable: <a href="https://www.google.com" rel="nofollow">https:&#x2F;&#x2F;www.google.com</a>, <a href="https://www.facebook.com" rel="nofollow">https:&#x2F;&#x2F;www.facebook.com</a>, <a href="https://www.svyft.com" rel="nofollow">https:&#x2F;&#x2F;www.svyft.com</a> as per the link provided in the article (<a href="https://shaaaaaaaaaaaaa.com" rel="nofollow">https:&#x2F;&#x2F;shaaaaaaaaaaaaa.com</a>)

So where is the fully automated solution for rotating certificates?<p>I&#x27;ve been looking for a CA who will provide an API to send the cert request, an easy way to prove the domain ownership which doesn&#x27;t involve SMTP, and the signed cert handed straight back from the API, but haven&#x27;t found it.<p>So far the most I&#x27;ve been able to streamline my certificate requests is to automate generating the CSR, skip setting the MX record, just bind SMTP to www.domain.com, get the validation email at &#x27;admin@www.domain.com&#x27; and auto-forward to my actual email address... so it&#x27;s <i>mostly</i> automated, but I still have to copy&#x2F;paste the cert request string into the CA&#x27;s webform, click the &#x27;Approve&#x27; link in the forwarded DV mail, and then copy&#x2F;paste the final cert from inside email back to the shell where it can finish the import.

Understanding that this is a naive outsider perspective, I find it strange that it&#x27;s any sort of emergency when a single collision has yet to be produced. And then, does the latest hash collision attack allow you to make a collision with a _specific_ target or just make a collision in general? Finally, even if you hit the target with some junk that happens to hash to the same thing, is it going to be in correct file format, and within an acceptable size? It seems like there are a handful of hurdles for the bad guys to go over before we&#x27;re in danger.<p>I know crypto is not to be taken lightly, and I&#x27;m glad people would rather be safe than sorry, and I&#x27;ll avoid SHA-1 in my own personal security use (`sha256sum` is sha-2 right?). I&#x27;m just curious.

An unrelated annoying thing: I want to disable TLSv1 support for my site, for obvious reasons. I don&#x27;t care about backwards compatibility for my personal site, but I still can&#x27;t flip the switch... because Googlebot doesn&#x27;t support anything newer than TLSv1.

Thank you google.<p>I&#x27;m a developer, but I&#x27;m not responsible for SSL cert acquisition.<p>The ONLY way I can get the people responsible for that to stop using SHA-1, is to tell them that user&#x27;s browsers are sending a warning&#x2F;error message on it.<p>I will eagerly await Chrome doing that.

It&#x27;s surprising how much energy Certificate Authorities invest into arguing about this. Instead, they should invest that energy into improving their SHA-2 support and helping their customers migrate.

Would be interesting to know how this affects Git version control, which has SHA-1 at its core.

One would think it would have been a good opportunity to change to SHA-2 after Heartbleed, since most websites had to get reissued certificates anyway. Since this process is a pain in the <i></i>* then one could have killed two birds with one stone at the time. Alas

Also its not exactly fair to compare the Flame attack on MD5 and compare it immediately to SHA-1. Unless you are the US or China you likely don&#x27;t have the resources necessary to pull off that sort of attack.<p>The Flame attack&#x27;s math was invented by an internal government cryptographic think tank. And still had to leverage massive computational power, just not in the order of 100&#x27;s of millions.<p>The idea a rogue group who have access to (both of) these resources is slightly idiotic. It would be far easier for them to attack RSA directly if you had 10&#x27;s of millions of dollars of computers. There are a lot of 1024 bit certs you could pick off for easy profit.

This article is amazing! I work in the SSL industry and this is a huge help in summarizing exactly whats going on.<p>@konklone, have you followed the CAB Forum&#x27;s mailing on this topic? Its the most I&#x27;ve seen them argue in well over a year.

Just to be clear, since I often end up confused on this point — is the use of SHA-1 with HMAC, outside of the context of SSL, still acceptable?

Seems like the SSL certificates that CloudFlare automatically generates for sites are SHA-1 signed.<p>Anyone know if they&#x27;re planning to upgrade to SHA-2?

The issue here is old clients... Does anyone know how old clients would handle SHA-2 certs, would they just get a warning saying the site is insecure but still be able to visit the site over an encrypted connection or do they break completely... I guess - I&#x27;ll have to run a few tests this afternoon and see how windows XP performs.

&quot;SHA1 and other hash algorithms generate a digital fingerprint that in theory is unique for each different file or text input they sign.&quot;<p>... and there it goes, any credibility I would give the author. There&#x27;s dumbing down the content for a non-technical audience, and there&#x27;s not understanding.

What does stop Google Chrome simply disallow new SHA-1 hashes that collide with known list of SHA-1 hashes for existing certificates?<p>That would allow non-colliding SHA-1 certificates function as usual and prevent millions of people from major headaches related to speedy certificate migration.

Or cut to the chase and just deploy DANE, so that we don&#x27;t need CAs to sign anything?<p><a href="http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;DNS-based_Authentication_of_Nam...</a>

I&#x27;m not saying the conclusion is wrong, but the reasoning likely is: there&#x27;s a <i>huge</i> difference between a collision attack and a so-called second pre-image attack [1]. To impersonate a website protected with an SHA-1 certificate you&#x27;d have to mount the second kind.<p>&gt; Walker&#x27;s estimate suggested then that a SHA-1 collision would cost $2M in 2012, $700K in 2015, $173K in 2018, and $43K in 2021.<p>If you adjust those cost estimates for the fact that a second pre-image is needed they look more something like this:<p>An SHA-1 second pre-image attack (needed to e.g. impersonate an SSL protected website) would likely cost about 10^26 USD in 2021... By comparison world GDP is only about 10^14 USD.<p>Better safe than sorry though. :)<p>1. <a href="https://www.ietf.org/mail-archive/web/pkix/current/msg30395.html" rel="nofollow">https:&#x2F;&#x2F;www.ietf.org&#x2F;mail-archive&#x2F;web&#x2F;pkix&#x2F;current&#x2F;msg30395....</a>

Can someone post a summary of the part of the story hinted to by the headline? I couldn&#x27;t find it.

When I use the sha tool against google.com, it shows them using SHA-1.

SHA1 is the only supported hash algorithm for PGP key fingerprints.

Ironically, www.google.com - Itself is using SHA-1 :)

Ironically, www.google.com itself is using SHA-1<p>Ref: <a href="https://shaaaaaaaaaaaaa.com/check/www.google.com" rel="nofollow">https:&#x2F;&#x2F;shaaaaaaaaaaaaa.com&#x2F;check&#x2F;www.google.com</a>

Another PR stunt Google ? No that wont work.