
Why Google is Hurrying the Web to Kill SHA-1 - mathias
https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1
======
tptacek
Two nits, both pedantic:

An attack on SHA1 that makes certificate forgery viable within the next few
years doesn't seem very likely, although over the long term it might be. The
attack on SHA1 isn'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.

Second, there'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.

~~~
xkiwi
Why SHA-2 instead of RSA 4096 or SHA-256? Even the RSA is compromised but
4096-bit will take a lot more(maybe few more hours) resources to decrypt.

==edited==

Thank you for the reply.

~~~
schmichael
SHA-256 is one of SHA-2's hash functions:
[http://en.wikipedia.org/wiki/SHA-2](http://en.wikipedia.org/wiki/SHA-2)

------
michaelbuckbee
A while back I launched a SSL scanner [1] and got tons of feedback from people
at Facebook, Google, Microsoft.

The most divisive item was how to represent SHA1 deprecation. The OPs article
doesn't really touch on it, but the reason that Google and everyone else
haven't moved on is that there still exist a sizeable number of clients that
can only accept SHA1 (and will error on anything else).

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're already doing things like only serving HSTS to
browsers that identify as Chrome, etc.

1 - [https://www.expeditedssl.com/simple-ssl-
scanner/scan?target_...](https://www.expeditedssl.com/simple-ssl-
scanner/scan?target_domain=google.com)

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

How would you do that? When the TLS connection is established you know nothing
about the client except its IP address. All of the interesting information
about the browser is transported via the HTTP stream which is tunneled
_inside_ the TLS connection.

HSTS is simple by comparison, as it's only an HTTP header.

~~~
sk5t
Not true; consider SNI as an example of the server choosing a certificate as
part of the handshake, without a cleartext exchange of the hostname.

[http://en.wikipedia.org/wiki/Server_Name_Indication](http://en.wikipedia.org/wiki/Server_Name_Indication)

~~~
Perseids
Actually the SNI extension _is_ sent in the clear. That's one of the things
TLS 1.3 is supposed to fix. (See e.g. [http://www.ietf.org/mail-
archive/web/tls/current/msg10484.ht...](http://www.ietf.org/mail-
archive/web/tls/current/msg10484.html) for a discussion about how to handle
SNI there). You have a point, though, in that the TLS extensions sent by the
client might give you some indication with what client you are talking with. I
would not hope for it though, and even if, such heuristics are hell of an ugly
hack inside the TLS stack.

------
higherpurpose
I'd like to see them gradually downgrade all non-PFS connections. Non-PFS
connections should be considered medium-to-highly vulnerable, and shouldn't
receive a green icon in browsers.

Unfortunately, they've just recommended everyone to use "2048-bit keys" when
they announced the HTTPS Google ranking policy. A lot of developers won't
understand the difference between a 2048-bit RSA key and a 256-bit ECC key, so
they'll just pick RSA, since "Google said 2048-bit keys!". Sooo...maybe this
policy will come in 10 years.

[http://googlewebmastercentral.blogspot.com/2014/08/https-
as-...](http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-
signal.html)

~~~
phlo
This seems to be a case of a slightly unfortunate wording.

Google calls for the use of 2048-bit key _certificates_ , a very reasonable
demand. In the forward secure use case, the certificate key is only used for
authentication. Using, say, ECDHE_RSA as your key exchange mechanism allows
for small but secure elliptic curve keys (EC), forward security (DHE) and uses
the certificate's RSA key for initial authentication (RSA).

Certificates can actually use ECDSA keys, and some companies will support this
(Symantec and CloudFlare off the top of my head), but I'm not exactly sure
about browser support. The chief advantage, as far as I know and assuming no
new breaks in RSA, is a strong reduction in certificate file size (256-bit vs
3k RSA equivalent), not forward security.

------
kajarya
Everyone is vulnerable: [https://www.google.com](https://www.google.com),
[https://www.facebook.com](https://www.facebook.com),
[https://www.svyft.com](https://www.svyft.com) as per the link provided in the
article ([https://shaaaaaaaaaaaaa.com](https://shaaaaaaaaaaaaa.com))

~~~
tptacek
Vulnerable to what? Perhaps better to say, "everyone would be vulnerable".

~~~
xkiwi
Https is to prevent wiretapping and man-in-the-middle attacks.

The problem now is even you established HTTPS connection, the weak SHA-1
encryption will not protect you.

~~~
tptacek
The SHA1 vulnerability being contemplated here affects only the establishment
of an HTTPS connection; the attack scenario involves obtaining a forged
certificate.

~~~
rictic
That's an especially pedantic correction, as it does not impact the meaning of
the statement.

s/the weak SHA-1 encryption/the weakened SHA-1 hash used to verify the
certificate that's used to authenticate the encrypted connection/

~~~
tptacek
It is, you're right. It's a hobbyhorse of mine, though, because SHA1 (and MD5)
appear in TLS ciphersuites as MAC components, and those uses are not known to
be vulnerable at all.

------
zaroth
So where is the fully automated solution for rotating certificates?

I'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't involve SMTP, and the
signed cert handed straight back from the API, but haven't found it.

So far the most I'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 'admin@www.domain.com' and auto-
forward to my actual email address... so it's _mostly_ automated, but I still
have to copy/paste the cert request string into the CA's webform, click the
'Approve' link in the forwarded DV mail, and then copy/paste the final cert
from inside email back to the shell where it can finish the import.

~~~
agwa
I'm working on this problem: [https://sslmate.com/](https://sslmate.com/)

Right now it's just a command line client, but a public API is in the works.
And this week we'll be announcing a solution to the cert rotation problem
(basically, you'll be able to drive your renewals from cron - it's going to be
really cool). You might want to follow @sslmate on Twitter - this is just the
beginning of some very exciting stuff for automating SSL cert deployment. Also
feel free to email me (address is in my profile).

Sadly, we're still SHA-1 only, because that's all that our certificate
authority (RapidSSL) supports at the moment. On the other hand, once we make
renewals dead simple, you can just buy 1 year certs and it won't be a big deal
upgrading to SHA-2 in a year's time. (After all, even Google is still using
SHA-1, but they can easily switch thanks to their 3 month certs and well-oiled
cert deployment machinery.)

~~~
zaroth
Very interesting, thanks! I unpacked the .deb, the nodejs source is pretty
easy to follow, so I'd say you pretty much already have the public API done.
;-)

The /link API is interesting, versus generating a token on your site through
the UI. You might want to consider allowing an explicit $$ limit on /buy,
since you store the api-key in the clear (albeit in a config file set to
0600).

It looks like you still rely on being able to receive an email on the domain
and click an approval link, though. I'm sure this is a RapidSSL requirement,
but it makes full automation more complex (certainly not impossible).

~~~
agwa
Thanks for checking it out! Yeah, it's really just a matter of documenting the
API ;-)

Unfortunately it does rely on being able to receive an email, as this is a
requirement of virtually all certificate authorities, though the email address
in the whois record is also an option (at least for TLDs which list the email
in whois). I have some ideas to make this easier for users who don't otherwise
receive mail at their domains, such as by letting them point their MX record
at sslmate.

A configurable $ limit on /buy is a very good idea; also I should make it
possible for users to use sslmate without permanently storing their API
credentials on the filesystem.

------
orblivion
Understanding that this is a naive outsider perspective, I find it strange
that it'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're in danger.

I know crypto is not to be taken lightly, and I'm glad people would rather be
safe than sorry, and I'll avoid SHA-1 in my own personal security use
(`sha256sum` is sha-2 right?). I'm just curious.

~~~
spatz
When a collision is produced it will be too late. The time to act is before
that happens.

~~~
orblivion
I guess that's the surprising part. I figured that that's just the first
hurdle, there's still the file length and format.

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

------
jrochkind1
Thank you google.

I'm a developer, but I'm not responsible for SSL cert acquisition.

The ONLY way I can get the people responsible for that to stop using SHA-1, is
to tell them that user's browsers are sending a warning/error message on it.

I will eagerly await Chrome doing that.

------
bla2
It'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.

~~~
mike_hearn
They are businesses. Their customers are mostly businesses. SHA1 is, for most
businesses that only want a padlock to reassure their customers, just peachy.
A CA that hassles their customers and says "you need to do complicated extra
work" is put at a disadvantage to other CA's that have a "customer is always
right" kind of attitude. Combined with tools that default to SHA1, and
customers that may depressingly actually have Windows XP SP2 terminals still
in production use, and you get feet dragging.

I don't think this is inherently a problem with the CA model. Rather it's what
you'd expect in a competitive market that is basically selling a binary
commodity product (a padlock icon), given textbook economics.

~~~
mlissner
What's weird though is that they have a consortium. They could have all agreed
simultaneously to stop issuing SHA1 certs years ago and at no market loss. But
they didn't.

~~~
mike_hearn
No. They've been quite clear about this. CA's are still selling SHA1 certs
because customers are asking for them. They're asking for them because they're
compatible with more apps/devices and - until now - browsers treated them the
same. So why sacrifice compatibility for no improvement.

The Chrome team are right to push this along, but I do have some sympathy for
the CA's here too. I read the whole discussion and it's pretty clear that
there was some epic miscommunication going on here. Notably Google thinks that
removing the padlock icon is not "deprecation" according to the timetable
Microsoft established, but all the people buying certs disagree; that's why
they're doing it.

~~~
avz
> So why sacrifice compatibility for no improvement.

No improvement? How about improvement in security?

~~~
mike_hearn
The reality is most people running websites that use SSL are not security
experts and cannot evaluate the weakness of SHA1 vs SHA2. So they trust the
defaults, which are SHA1 (in e.g. openssl). Their goal is to get the padlock,
not to achieve some other notion of security.

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

~~~
simias
I assume you would need to forge a meaningful (and potentially harmful) commit
with the same SHA-1 as an existing one to do arm. That's probably more
difficult than forging an SSL certificate (since the actual contents of the
blob are more constrained that the certificate file, probably). I'm also not
really sure what would happen if commits made after the "compromised" one
happened to conflict with it but I'm pretty sure the devs would notice
something fishy going on pretty quickly.

That being said git/mercurial and friends will have to transition to an other
hashing algorithm sooner or later but it's not as urgent as web certificates
security-wise.

~~~
0x0
I'd think the content of the blob is less constrained, because you can put
whatever padding fluff you need at the end of the commit message to adjust the
sha1 of the commit. To cause harm, you'd include the trojanized code in a
different file which your colliding commit blob references. (So, you'd need to
include multiple blobs, but only the commit-message one needs to collide with
an existing one)

A collision in commit hashes would mean you could no longer trust a signed
tag, for example.

Look up the old stripe-ctf "gitcoin" challenge and you'll see it really is
quite easy to meddle with commit hashes :)

------
hevsuit
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 __* then one could have killed two birds with
one stone at the time. Alas

~~~
konklone
In fact, Heartbleed helped a lot:
[http://news.netcraft.com/archives/2014/05/05/sha-2-very-
cryp...](http://news.netcraft.com/archives/2014/05/05/sha-2-very-
cryptographic-so-secure-such-growth-wow.html) But there's a long way to go.

------
valarauca1
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't have the
resources necessary to pull off that sort of attack.

The Flame attack'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's of millions.

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's of millions of dollars of computers. There are a lot of 1024 bit
certs you could pick off for easy profit.

~~~
brador
Botnet.

~~~
valarauca1
As I stated.

The computation power needed to break SHA-1 is higher then attacking RSA. So
if you are financially motivated attacking RSA has a higher ROI.

~~~
squeaky-clean
While true, "There's something more profitable to attack at the moment" seems
like a lousy way to handle security.

~~~
valarauca1
I never said moving away from SHA-1 was irrelevant. I was simply stating that
they were overestimating how common the FLAME attack could be pulled off.

Flame like Stuxnet are state of the art. Highly funded state of the art. A lot
of security researchers look at these things and simply say, "Are you shitting
me?!"

Call me optimistic but I highly doubt we'll be uncovering a new stuxnet every
single year.

------
vtlynch
This article is amazing! I work in the SSL industry and this is a huge help in
summarizing exactly whats going on.

@konklone, have you followed the CAB Forum's mailing on this topic? Its the
most I've seen them argue in well over a year.

~~~
konklone
I have, it's one of the links in there. I truly loved reading that discussion.

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

~~~
Perseids
The use of SHA1 with HMAC, _inside_ as well as outside of the context of SSL
is still acceptable, yes. Even against a nation state attacker. The reason
attacks on HMAC(k,m)~=SHA1(k||SHA1(k||m)) are much more difficult than general
collision attacks is that as an attacker you do not know the internal state of
the hash function when you are trying to create a collision with m, as the
secret key is input in the hash function first.

The attack vector for TLS certificates is the (asymmetric) _signature_ which
signs a plain SHA1 hash message. I'm still disappointed that after all the
experiences they have had with MD5 they haven't yet started to randomize the
hash in the signature (sign SHA1(random||message) instead of SHA1(message) )
which would boost the signature security to that of HMAC.

------
kilovoltaire
Seems like the SSL certificates that CloudFlare automatically generates for
sites are SHA-1 signed.

Anyone know if they're planning to upgrade to SHA-2?

~~~
konklone
They can be seen in the Chrome discussion thread, complaining to Google that
the timeline is too aggressive. But they're a good company, and I imagine
they'll update as soon as they can.

~~~
kilovoltaire
Ah interesting, thanks.

(For anyone else, here's the link:
[https://groups.google.com/a/chromium.org/d/msg/blink-
dev/2-R...](https://groups.google.com/a/chromium.org/d/msg/blink-
dev/2-R4XziFc7A/cLDiqrrnkPkJ))

~~~
tptacek
This is a great thread. Thanks for posting it.

------
taf2
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'll have to run a few tests this afternoon and see
how windows XP performs.

~~~
bpoyner
Please let us know. Here's a table showing when SHA-2 support was added to
various browsers.

[http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_br...](http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers)

~~~
rythie
I've seen in a lot of places that Chrome only supported SHA-2 since version 26
(2013). I find this hard to believe (Firefox supported it since 2005) and I
can't find a solid reference for it. However I note that this page from 2008,
says Chrome supports it [https://www.tbs-
certificates.co.uk/FAQ/en/476.html](https://www.tbs-
certificates.co.uk/FAQ/en/476.html) (e.g. from version 1)

------
brongondwana
"SHA1 and other hash algorithms generate a digital fingerprint that in theory
is unique for each different file or text input they sign."

... and there it goes, any credibility I would give the author. There's
dumbing down the content for a non-technical audience, and there's not
understanding.

~~~
blibble
what's wrong with that statement exactly?

~~~
silentOpen
Two things:

1\. Hashes don't "sign" things (not directly anyway)

2\. Hashes aren't unique in theory or practice (using a 256-bit hash on every
257-bit number will generate 2^256 collisions by the pigeonhole principle).

~~~
Retric
High quality hashes are unique in practice.

Suppose every person generates 1 billion files a second * 7 billion people *
1,000 years = ~3x10 ^ 28 call it 10^29. For a collusion among non identical
files using a good 256 bit hash you get ~1/(2^256) * (10^29) * (10^29) =
~1/(2^198).

Or 1 chance in ~4 * 10 ^ 59 of finding even one collision.

~~~
nly
Your math is off a bit[0][1] but you're right, it's a vanishingly small
probability of a single collision. This is fairly academic though, when you're
talking about an adversary exploiting weaknesses in the algorithm itself, and
not a perfect PRF.

[0] [http://preshing.com/20110504/hash-collision-
probabilities/](http://preshing.com/20110504/hash-collision-probabilities/)

[1]
[http://www.wolframalpha.com/input/?i=%281+billion+*+7+billio...](http://www.wolframalpha.com/input/?i=%281+billion+*+7+billion+per+second+*+1000+years%29^2+%2F+%282+*+2^256%29)

~~~
Retric
Ops, when counting exponents make sure there in the same base.

------
dennisgorelik
What does stop Google Chrome simply disallow new SHA-1 hashes that collide
with known list of SHA-1 hashes for existing certificates?

That would allow non-colliding SHA-1 certificates function as usual and
prevent millions of people from major headaches related to speedy certificate
migration.

------
foomen
Or cut to the chase and just deploy DANE, so that we don't need CAs to sign
anything?

[http://en.wikipedia.org/wiki/DNS-
based_Authentication_of_Nam...](http://en.wikipedia.org/wiki/DNS-
based_Authentication_of_Named_Entities)

------
bjornsing
I'm not saying the conclusion is wrong, but the reasoning likely is: there's a
_huge_ 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'd
have to mount the second kind.

> Walker's estimate suggested then that a SHA-1 collision would cost $2M in
> 2012, $700K in 2015, $173K in 2018, and $43K in 2021.

If you adjust those cost estimates for the fact that a second pre-image is
needed they look more something like this:

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.

Better safe than sorry though. :)

1\. [https://www.ietf.org/mail-
archive/web/pkix/current/msg30395....](https://www.ietf.org/mail-
archive/web/pkix/current/msg30395.html)

------
raldi
Can someone post a summary of the part of the story hinted to by the headline?
I couldn't find it.

~~~
squeaky-clean
It's one of the links early in the story. (It's pretty link heavy, so it can
be hard to miss. 6th link in).

Basically, by 2015, Google will update Chrome to show websites with HTTPS
certificates using SHA-1 as "insecure." The level of insecurity shown will get
more severe over time, as well as being based on when your certificate
expires. Here is the full link for details:

[http://googleonlinesecurity.blogspot.com/2014/09/gradually-s...](http://googleonlinesecurity.blogspot.com/2014/09/gradually-
sunsetting-sha-1.html)

~~~
raldi
That's _What_. The headline hints at _Why_ , but never delivers.

~~~
squeaky-clean
This entire article is about Why. Read the "An attack on SHA-1 feels plenty
viable to me" section for the most info.

~~~
raldi
I see -- it's not announcing any news, or any new theories; it's just a
roundup of last week's news.

~~~
gbhn
Yes. Much like last week's news was. :-)

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

~~~
zachberger
Google has stated they wont complete their transition until 2015

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

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

------
ankit428
Ironically, www.google.com itself is using SHA-1

Ref:
[https://shaaaaaaaaaaaaa.com/check/www.google.com](https://shaaaaaaaaaaaaa.com/check/www.google.com)

------
blueking
Another PR stunt Google ? No that wont work.

