
Phasing Out SHA-1 on the Public Web - kungfudoi
https://blog.mozilla.org/security/2016/10/18/phasing-out-sha-1-on-the-public-web/
======
niftich
Chrome [1], Edge, and IE [2] are also in various stages along between the
continuum of not marking SHA-1 secure, warning about SHA-1, or blocking it
altogether.

[1] [https://security.googleblog.com/2015/12/an-update-on-
sha-1-c...](https://security.googleblog.com/2015/12/an-update-on-
sha-1-certificates-in.html)

[2]
[https://blogs.windows.com/msedgedev/2016/04/29/sha1-deprecat...](https://blogs.windows.com/msedgedev/2016/04/29/sha1-deprecation-
roadmap/)

EDIT: My frustration is that it's a bit difficult to grok who's warning
against what when, and who's blocking what when, and who's giving unskippable
errors to what when but I'll try to collect and distill this down because
right now I have to look it up every time on blog posts that haven't been
updated in years (-cough- Google)

~~~
toast0
The short version is, if you care about modern browsers, you should be using
SHA-256 already. If you care about ancient clients, you should be using SHA-1
still. If you care about both, you need to serve both[1], but your SHA-1 cert
most likely expires at the end of this year anyway, unless you've gone through
the effort for extraordinary issuance.

[1] you'll most likely need to write code for this, I don't think it's widely
supported. If you send SHA-1 to TLS1.0 and SSLv3, that's probably easier than
triggering off the signature algorithms extension.

~~~
tinalumfoil
> If you care about ancient clients, you should be using SHA-1 still

I want to point out here that the oldest OS the newest Firefox supports is
Windows XP SP2 [0], released 8 years ago, and a free upgrade from the original
XP release 14 years ago. Unless you need support for last millennium's
hardware you have no excuse for not supporting SHA-256.

[0]
[https://en.wikipedia.org/wiki/Firefox#System_requirements](https://en.wikipedia.org/wiki/Firefox#System_requirements)

~~~
toast0
Note that I contrasted modern browsers and ancient clients. Client libraries
in shipped devices tend to be several years behind state of the art when they
were shipped, and live in the field without updates. As an example Symbian
didn't ship SHA-256 support in their 9.3 release from 2006, but Firefox
shipped support in their 1.0 release from 2004.

Whenever TLS 1.0 starts getting pulled from servers, it's going to be
similarly painful. Nokia S40/Asha (last device released in 2014), only
supports TLS 1.0, even though TLS 1.2 was 6 years old at that point. Nobody
meaningfully supports TLS 1.1, but not TLS 1.2, so let's not hold lack of TLS
1.1 support against them.

(Not to pick on Nokia, they just happen to be an easily identifiable client
platform that I'm familiar with)

------
MichaelMoser123
The funny thing is that data deduplication storage systems work on sha-1
hashes to identify identical data blocks (two blocks are considered equal if
the hash is equal - most systems don't care to check for collisions); they
kept telling that the likelyhood of collisions is so astronomically small [1]
; i wonder if this statement is still considered to be true.

[1] [https://pibytes.wordpress.com/2013/02/09/deduplication-
inter...](https://pibytes.wordpress.com/2013/02/09/deduplication-internals-
hash-based-part-2/)

~~~
johnmaguire2013
I think many systems use two hashing methods to verify this claim (e.g. SHA-1
and MD5.) Are there any known collisions that affect both algorithms?

~~~
yoha
You are talking about making a combined hash function from MD5 and SHA-1. Keep
in mind that it is not trivial. For instance, if you just output both SHA-1
and MD5, you are actually only as strong as the weakest hash function
(trivially for preimage, but also true for collisions, see [1]).

If you are interested in hash function combiners, have a look at _Robust
Multi-Property Combiners for Hash Functions_ [2], a recent paper on the topic.
It aims at getting several properties at the same time (preimage resistance,
collision resistance). For simpler schemes with a single property, just
explore the bibliography at the end of the paper.

[1]
[https://cryptopals.com/sets/7/challenges/52](https://cryptopals.com/sets/7/challenges/52)

[2] [https://eprint.iacr.org/2016/723](https://eprint.iacr.org/2016/723)

~~~
xeeeeeeeeeeenu
What you are saying is completely irrelevant, because we are talking about
checksumming data, not hashing passwords.

------
0x0
Disabling SHA1 for only a subset of Firefox 51 users after release sounds like
it'll cause a lot of confusion. "Is my computer hacked?" "It works for me!"
etc etc

~~~
AstroJetson
Another good reason to not do the nonstop upgrades that FF keeps coming up
with. I'm hanging in the upper 40's until this shakes out.

I understand SHA1 is an issue, but I'm also confused by some things. Happy to
have web pages be encrypted to keep my personal information from being
captured. Not really sure why we are encrypting video streams from Youtube. Is
a cat video something that we need to make more secure?

And I agree with the comment that the problems are now coming back to the
plethora of CA's that have popped up in the last few years.

~~~
vog
_> Is a cat video something that we need to make more secure?_

This is about solidarity by increasing the background noise. If only those
people who really need it would use encrytion, they were easy to detect and to
suppress.

So, please show solidarity with the weak people in our and other societies by
encrypting as much non-sensitive stuff as possible.

~~~
AstroJetson
Thanks for the thought out reply, that makes the most sense.

------
user5994461
Summary:

> per recommendations by NIST, issuance of SHA-1 certificates halted for the
> web last January.

> In early 2017, Firefox will show an overridable “Untrusted Connection” error
> whenever a SHA-1 certificate is encountered.

~~~
r1ch
> overridable “Untrusted Connection” error

Allowing users to click past security warnings is a really bad idea. How is a
user supposed to know the difference between untrusted because of SHA-1
deprecation and untrusted because of a MITM?

~~~
kkl
As far as I know almost all browser security warnings are overridable. The
only one that comes to mind that does not have a click-through option is when
a HSTS-enabled site fails a validation check.

~~~
r1ch
This one in particular feels very strange, since there's actually nothing bad
actively happening with the connection, it's more of a policy decision.

~~~
coldpie
My understanding is that you can't _know_ that nothing bad is actively
happening with the connection since SHA-1 is no longer a strong hash, so it's
basically (hand-wave) no different from an HTTP connection.

~~~
bandrami
So why don't they present any warning on HTTP connections?

It's not "basically no different" from an HTTP connection, it's _strictly
better_ than an HTTP connection, but not as good as a cert made with a more
modern hash. (For that matter the same argument applies to self-signed
certificates: you're still keeping a third party from snooping on the phishing
attempt the MITM is giving you, which is itself a Good Thing.)

~~~
kevincox
All major browsers are moving towards this. Starting with the tiny icons
changing colors they are beginning to make HTTP as insecure. Yes, it's very
slow but at least they have started moving.

------
SiVal
Should SHA-1 be phased out of git, too? I understand that it's more of an
issue for certs, but it's still a bit of an issue for anything that uses
SHA-1. I'm just asking, not advocating, because the answer will depend on both
benefits and costs, and I don't know enough about either in the case of git.

~~~
kevincox
I don't think git's use was really intended for security. That being said it
would be interesting to upgrade it and achieve security.

~~~
petertodd
Regardless of whether or not it was intended for security, it is used for
security now, via signed git commits and git tags. Lots of projects rely on
them, and there aren't good alternatives yet; using third-party services like
GitHub without signed git commits is very foolish.

Fortunately it's only becoming possible for attackers to create _pairs_ of
messages that have the same SHA1 hash; an attacker still can't create a
collision between a message of their choosing and an arbitrary SHA1 hash, and
that type of attack is probably a long way off. But that's not much safety
margin!

~~~
ploxiln
A scheme to generate (and sign) a SHA512 hash that more directly incorporates
the full state of the repo was invented, and is used by some projects incl.
nodejs

[https://github.com/cgwalters/git-evtag](https://github.com/cgwalters/git-
evtag)

[https://github.com/nodejs/node/issues/7579](https://github.com/nodejs/node/issues/7579)

I personally think it's overkill

~~~
petertodd
Oh, interesting! I do something not unlike that with my OpenTimestamps git
commit signing: [https://petertodd.org/2016/opentimestamps-git-
integration](https://petertodd.org/2016/opentimestamps-git-integration)

I don't describe it in that post unfortunately, as I still consider the git
tree "rehashing" support to be alpha-level, but I'll look into git-evtag.

------
jlgaddis
Red Hat uses SHA1 certificates for their CDN [0] (that provides packages for
RHEL7 and, I assume, other products).

It is a "private PKI" but their (current) intermediate and root certificates
do not expire for a long, long time. Hopefully they'll move to a SHA256 root
in the near future.

[0]: [https://cdn.redhat.com/](https://cdn.redhat.com/)

~~~
iancarroll
The hash algorithm of a root certificate does not matter, because you
explicitly trust the root certificate, and it is only signed by itself.

Their intermediates and end-entity certificates should be updated, but still,
the attacks PKIs are concerned about on SHA1 (a preimage attack) can only
happen during issuance.

However, if a second preimage attack on SHA1 were viable, all of the above
would be invalid, and SHA1 would be permanently weakened for all digital
signature uses.

------
Cyph0n
Honest question: why does a SSL certificate need SHA-2? In other words, where
does hashing factor into the asymmetric crypto process? So from my cursory
understanding of SSL, it uses RSA to exchange a symmetric key which is then
used for the remainder of the session.

I'm interested in crypto systems but still getting my feet wet, so a
simplified answer would be really appreciated! Also, pointers to any articles
or papers would be great.

~~~
Rafert
It's the hash of the certificate that is signed by a CA. Create a certificate
with the same hash and you can transplant the signature.
[http://web.archive.org/web/20071226014140/http://www.cits.ru...](http://web.archive.org/web/20071226014140/http://www.cits.rub.de/MD5Collisions/)
demonstrates this with the MD5 hashes of two different PDF files, a letter of
recommendation and a security clearance.

It's common to sign hashes instead of the data, reasons are explained here:
[http://crypto.stackexchange.com/questions/12768/why-hash-
the...](http://crypto.stackexchange.com/questions/12768/why-hash-the-message-
before-signing-it-with-rsa)

~~~
Cyph0n
So basically it's used to verify a MAC?

What I'm imagining: CA takes the hash of the certificate, encrypts that with
its private key, and appends it to the cert. Client's browser then takes hash
of locally stored certificate, and uses the CA's public key to check that the
MAC attached to the incoming cert is valid.

I'm guessing SSL uses RSA-PSS[1] or something similar. Guess I'll have to do
some reading when I find the time.

[1]: [http://www.onefs.com/emc-plus/rsa-labs/historical/raising-
st...](http://www.onefs.com/emc-plus/rsa-labs/historical/raising-standard-rsa-
signatures-rsa-pss.htm)

~~~
iancarroll
Certificates have a "tbsCertificate" component which holds almost everything
(issuer, expiry, distinguished name, etc) except for the signature. The CA
takes HashAlgo(tbsCertificate) and signs it with its issuing key.

The relying party can then take HashAlgo(tbsCertificate) and see if the CA
signed that value.

Make sure you do not confuse encryption with signing. The hash is not private,
so you do not need to hide its contents. I'm not sure if you can call it a
MAC, because there is no key involved. It provides integrity guarantees, but
the hash itself does not provide any authenticity guarantees; only the signed
hash does.

~~~
Cyph0n
Awesome. Thanks for the clear explanation!

------
bandrami
Doesn't matter when you have CAs known to have backdated certificates to avoid
the SHA-1 deadline and all they get is a temporary suspension with none of
their issued certs being revoked. The weak point of PKI is not the crypto,
it's the CAs, of which there are too many and for whom there is little to no
accountability.

~~~
icebraining
It wasn't just a suspension - they got kicked out and may only _reapply_ after
a year. Only if they pass strict scrutiny will they ever be re-admitted.

~~~
snuxoll
Not to mention not being able to do business effectively for a year is
basically a death sentence.

"We sell certificates, but they won't work in Firefox, and maybe Chrome or IE
if Google and Microsoft follow suit". Doesn't exactly sound like a vendor I'd
purchase anything from.

------
ptaipale
Do I understand correctly, when Mozilla says:

 _In early 2017, Firefox will show an overridable “Untrusted Connection” error
whenever a SHA-1 certificate is encountered that chains up to a root
certificate included in Mozilla’s CA Certificate Program. SHA-1 certificates
that chain up to a manually-imported root certificate, as specified by the
user, will continue to be supported by default; this will continue allowing
certain enterprise root use cases, though we strongly encourage everyone to
migrate away from SHA-1 as quickly as possible._

This means that self-signed certificates, approved as an exception in browser,
will continue to work because they are do not chain up to a root certificate
included in Mozilla’s CA Certificate Program? I.e. if user has confirmed an
exception for self-signed certificate, it is not impacted by this change in
Mozilla?

~~~
kevincox
The signature on a self signed certificate doesn't matter as the certificate
itself is trusted.

However if you add your own CA then yes, I believe it will continue to work
for the near future. (You should be moving away anyways though ;) )

------
jlgaddis
If you want to test out this behavior before it rolls out, you can set
security.pki.sha1_enforcement_level (per Gervase Markham).

A value of 1 means "entirely forbidden", a value of 3 means "forbidden for
public roots".

I can't speak for the behavior when using any other value.

------
d33
What about BitTorrent? It also heavily uses SHA1 - basically for everything
from computing infohash to data integrity checks.

~~~
TazeTSchnitzel
Well, a nation state attacker might be able to produce a fake block filled
with garbage for a file and have your client accept it.

Unless BitTorrent relies on digital signatures somewhere, that's probably the
worst of it.

~~~
d33
Or worse, use it to infect the victim if it's executable/exploitable.

------
jlgaddis
They say that this won't affect any SHA1 certificates signed by a root that
has imported and trusted, but there's a lot of devices that ship with their
own self-signed certificates installed. I hope all the vendors have away from
SHA1 or there might be a lot of "broken" devices.

~~~
kevincox
Remember that if you are trusting the cert itself this is irrelevant because
you aren't verifying the chain (which is the part using the SHA1 hash). I
presume this is what most embedded devices do. But yes, if you imported a SHA1
root you should probably consider distrusting it.

------
DyslexicAtheist
what about retiring TLS 1.2 then?

[banking industry gasps]

~~~
toast0
Did you mean TLS 1.0? Retiring 1.2 seems a bit premature, since 1.3 isn't
finalized.

~~~
DyslexicAtheist
no I was talking TLS 1.2

[https://www.ietf.org/mail-
archive/web/tls/current/msg21278.h...](https://www.ietf.org/mail-
archive/web/tls/current/msg21278.html)

------
cheiVia0
What about git? It also heavily uses SHA1

~~~
majewsky
See this sibling thread about the same topic:
[https://news.ycombinator.com/item?id=12738567](https://news.ycombinator.com/item?id=12738567)

