
SHA-1 Deprecation Update - robin_reala
http://blogs.windows.com/msedgedev/2015/11/04/sha-1-deprecation-update/
======
iamsohungry
If the cost of creating a collision is $75K, it's _far_ too late to be
deprecating SHA1.

Even if everyone were to somehow remove SHA1 instantly _now_ , there is stuff
that has (for example) been authenticated using SHA1-HMAC over the last year
which will still be relevant for years. It's not hard to think of cases where
spoofed messages from a user a year ago are useful to a malicious attacker.

~~~
mtgx
Exactly why Google moved to an "aggressive" timeline to deprecate SHA-1.
Schneier predicted the cost of SHA-1 collisions _years ago_ and said _criminal
groups_ will be able to create collisions by 2018 - which means you needed to
start pushing for killing SHA-1 support _years earlier_.

But when Google did that everyone jumped on them for "trying to control the
Internet" or something (because obviously trying to make the Internet adopt
stronger security is a power tripping thing). I hope at least now they've seen
the error in their ways.

Oh, and it turns out Schneier was actually _too optimistic_ about the costs of
SHA-1 collissions - by about an order of magnitude:

> 211 * 28.4 = 219.4 ~ $700K by 2015

[https://www.schneier.com/blog/archives/2012/10/when_will_we_...](https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html)

~~~
danudey
And Google's push to deprecate SHA-1 to try to drag the internet into modern
security practices pales in comparison to Apple's ATS implementation, which
has a brutally modern set of minimum requirements (TLS1.2, 256-bit elliptic
curve, SHA-256, 2048-bit RSA key).

And given Apple's extremely vocal stance on privacy and security, and their
'sudden' addition of ATS, it wouldn't surprise me if ATS became a hard
requirement in iOS 10.

~~~
yuhong
ATS has nothing to do with web browsing though.

------
zmmmmm
The basis of it is interesting to me: breakthroughs in finding collisions have
lowered cost estimates to about $75k to break a single collision (based on GPU
rented from Amazon EC2). It's interesting to see it quantified that way.

~~~
steckerbrett
I would prefer it be measured in size of botnet. Criminals don't use EC2. They
use hacked boxes. They have no cost beyond compromising the machine.

~~~
danudey
Sure, but it provides an interesting context. $75k at Amazon's EC2 prices
gives you a good idea of what the ballpark is - i.e. reasonably accessible for
any large organization, esp. criminal organizations.

If EC2 can collide SHA-1 with $75k of rented GPU time, imagine how trivial it
is for an organization willing to buy $100k of dedicated GPU compute hardware
to devote to colliding SHA-1 certificates. You don't even _have_ to botnet
once you have enough working capital.

Never mind how trivial it is for an organization like the NSA or GCH to do
this sort of thing with their existing hardware.

~~~
steckerbrett
Just to note, with large GPU farms the cost of the power to run them will
exceed the hardware cost in a matter of weeks.

------
MichaelGG
If certs would have included both MD5 and SHA1 signatures, and required both
to match, would that have bought a lot of safety? What if another hash had
been added too? Because then you'd need to find simultaneous collisions across
multiple functions, which at least sounds a lot tougher. But perhaps not?

~~~
bdamm
Combining weak hashes doesn't provide any assurance. Let's assume that finding
a new way to break MD5 is a rite of passage into certain professional
cryptoanalyst circles. Do you know what they know?

Besides, there are no X509 signature types that are a combination. You'd need
to update browsers... and it would be much easier to just update your hash.

~~~
MichaelGG
Well I'm thinking more along the lines of future-proofing designs. Like right
now, should a new protocol use both SHA2 and SHA3, just to be safe?

~~~
viraptor
"new protocol" is likely going to be less secure than TLS1.2. And TLS1.2
doesn't allow multiple signatures - it's usually in the form of
"(hash)-with-(encryption)" (for example oid 1.2.840.113549.1.1.5 - SHA-1 with
RSA Encryption) and since that's embedded in the hashed contents, you can't
easily add new signatures that require specific parameters.

~~~
MichaelGG
I don't mean related at all to TLS. I mean in general, is the principle of
using multiple algorithms that bad? If, in an alternative universe certs were
signed with MD5 and SHA1, would that not have been a practical defense to buy
some more time? And thus for new, incompatible protocols, is it not a safer
choice to use a couple of algorithms? That way if SHA2 or 3 are found to have
some terrible weakness, you're still OK. And if practical attacks are found on
both, it still might not mean that such attacks work _together_?

There's a bit of precedent in 3DES which just runs the same algorithm 3 times
in a row... Which I guess you could do by using the same hash algorithm
several times on the same input plus some fixed data or transform. So even
though you can find two inputs a and b that h(a) = h(b), you might not be able
to get h(f(a)) = h(f(b)) hmm? (Though I understand certain hash attacks will
do exactly that for certain values of f.)

------
mtgx
While Microsoft is still debating whether it should disable SHA-1 in mid-2016,
early 2017 or at the end of 2017, Google is already moving to require all
certificates to support Certificate Transparency, to vastly increase the trust
we can put in Certificate Authorities. As per their article they are still
only "considering" removing SHA-1 support by mid-2016.

Microsoft needs to stop wasting time with _obvious_ stuff (like deprecating
SHA-1, RC4, MD5, and all that), and be a little more aggressive with securing
their products as well.

~~~
danudey
Keep in mind that Microsoft is a large organization, and they have to
carefully consider which action is actually 'the greater good'. For example,
making a breaking change (like deprecating SHA-1 in Edge) _might_ force
external developers/vendors to update their servers to SHA-256, but it might
also encourage enterprises to avoid updating to Windows 10 entirely, and,
overall, that's far worse than letting SHA-1 certificates kick around for
another six months (especially since those certs won't work with iOS 9,
Chrome, or Firefox anyway).

Apple can get away with ATS because for every service/site/app that doesn't
bother to update, there are ten other apps waiting in the wings to steal your
users. On Windows, there's little incentive for most people to upgrade, and
strong existing disincentives for enterprises/schools/organizations.

------
skuhn
Good, they should accelerate it.

However, I wish that Microsoft made it extremely clear in these announcements
that root certificates are not subject to SHA-1 collision attacks. Certain
people [1] have misunderstood the situation and removed trust for SHA-1 signed
roots (and that project is definitely not alone). Mozilla's announcement [2]
does draw a distinction, but it's quite easy to miss. CAs like Entrust are
much more clear about this, since their business relies on it.

It is security theater [3] to tell users that they shouldn't use a SHA-1
signed root if they want their connections to be secure. Security
vulnerabilities need to be very simply and clearly communicated -- otherwise
you get solutions based on preconceived notions and simplistic "X is always
BAD" thinking that do more harm than good.

In this instance, people have spent days debugging connectivity issues and
opening tickets with service providers. And the reasoning behind the move is
not based in fact -- Mozilla has NOT removed SHA1 certs from their trusted
roots [4] and they have announced no timetable in which to do so. It's simply
because someone heard "SHA-1 is bad" and acted accordingly.

The current SHA-1 deprecation push applies only to chain and end certificates,
_not to roots_ \-- removing trust for SHA-1 signed roots is not necessary to
prevent these sorts of attacks and it is much too soon to take that step in
any environment that talks to systems which you don't control on the public
Internet.

[1] [http://certifiio.readthedocs.org/](http://certifiio.readthedocs.org/)

[2] [https://blog.mozilla.org/security/2015/10/20/continuing-
to-p...](https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-
sha-1-certificates/)

[3] [https://github.com/certifi/python-
certifi/issues/26#issuecom...](https://github.com/certifi/python-
certifi/issues/26#issuecomment-147962495)

[4]
[https://mozillacaprogram.secure.force.com/CA/IncludedCACerti...](https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport)

------
ddlatham
Can anyone point to an existing published SHA-1 collision?

~~~
nemothekid
FTA:
[https://sites.google.com/site/itstheshappening/](https://sites.google.com/site/itstheshappening/)

There are freestart collisions, but no actual collisions yet.

~~~
ddlatham
It seems surprising that if it's that cheap to find one no one has credibly
claimed to have done it yet.

------
sarciszewski
Slight nitpick: I wish they would use the term "other browser suppliers"
instead of "other browser vendors", as Firefox, Chrome, Opera, etc. are not
sold for money, they are supplied for free.

But this is good news. Die SHA-1, die!

~~~
tptacek
I'm confused; IE isn't sold for money either.

~~~
sarciszewski
Now I'm confused, because I didn't ever imply that it was.

