
SHA1 sunset will block millions from encrypted net, Facebook warns - pavornyoh
http://arstechnica.com/security/2015/12/sha1-sunset-will-block-millions-from-encrypted-net-facebook-warns/
======
nivla
Interestingly I was all for this until one day when I wasn't able to log into
my Router's page. The router used a self signed SHA1 certificate and Chrome
outright refused to render it. Gladly the router was open to dd-wrt and I was
able to replace the certificate manually. However I wonder how many other
devices are there which people can't update that may be affected because of
this.

~~~
gist
"Interestingly I was all for this until one day when I wasn't able to log into
my Router's page. The router used a self signed SHA1 certificate and Chrome
outright refused to render it. Gladly the router was open to dd-wrt"

Couldn't you just have logged in with another browser or an older browser?

~~~
pyre
Your router is broken. Your router supplies your Internet connection. "Just
hop on ye olde Internet and get an older browser."

(Also, how exactly does this work if you are not one of the tech literate?)

~~~
gist
Well you've got a good point actually however the parents statement (that I
was replying to) does say this which requires a bit more tech literacy, eh:

"Gladly the router was open to dd-wrt"

On a fun note not sure if you remember the old "Get Netscape Now!" icons that
were at the bottom of nearly every 90's webpage which, to your point, was as
if someone visited your site and would actually pause to download and install
a new browser (over dialup no less) if it didn't render correctly. [1]

[1]
[http://sillydog.org/netscape/now.html](http://sillydog.org/netscape/now.html)

------
vaadu
The internet can never get more secure if it has to cater to the least secure.

~~~
geofft
In this particular case, Facebook is advocating for using a SHA-1 certificate
only if they know that the client doesn't support SHA-256, and if that
knowledge is cryptographically protected. Since TLS supports a way of securely
detecting MITMs in the handshake, you can in fact get the client TLS version
in a trustworthy manner. This prevents SHA-1 attacks on clients that support
SHA-256 (which was the goal all along), while continuing to provide non-
plaintext service to clients that don't.

It's not at all clear to me that this prevents the internet from getting more
secure.

~~~
agwa
> In this particular case, Facebook is advocating for using a SHA-1
> certificate only if they know that the client doesn't support SHA-256, and
> if that knowledge is cryptographically protected. Since TLS supports a way
> of securely detecting MITMs in the handshake, you can in fact get the client
> TLS version in a trustworthy manner. This prevents SHA-1 attacks on clients
> that support SHA-256 (which was the goal all along), while continuing to
> provide non-plaintext service to clients that don't.

Their proposal doesn't actually stop SHA-1 attacks. If an attacker can forge a
SHA-1 cert, they can set up a MitM in which the victim talks exclusively to
the attacker's server. Facebook's servers won't be contacted, so the
downgrade-proof logic on Facebook's servers won't even be executed. The
attacker's server will present only the forged SHA-1 certificate, which web
browsers will accept in the name of backwards compatibility. Long-term,
browsers will stop accepting SHA-1 certificates, but this is not scheduled to
happen until 2017.

> It's not at all clear to me that this prevents the internet from getting
> more secure.

Two ways this prevents the Internet from getting more secure:

1\. Their proposal would make it possible to obtain SHA-1 certificates past
December 31, 2015, which means there's more time for an attacker to exploit a
collision to forge a cert. It's important to understand that exploiting a
SHA-1 collision requires a certificate authority to issue you a certificate,
so if no one is able to find a SHA-1 collision in the next 19 days, the
Internet will be safe from SHA-1 collisions in 2016 even if browsers continue
to accept SHA-1 certificates until 2017. Allowing continued SHA-1 issuance
removes this safety net.

2\. It sends the message to companies that deadlines can be ignored because
they'll be pushed back at the last minute. This will make it difficult to
deprecate insecure practices in the future.

~~~
geofft
Facebook's proposal is that only organizations that are a) demonstrably using
this technique and b) validated at a higher level than automatic domain
validation be allowed to get new SHA-1 certs. This means that an attacker will
have to identify themselves fairly strongly in order to conduct a collision
attack. It is a vast improvement from anyone being able to register a random
new domain name and get a SHA-1 cert for it. It's probably not a huge
roadblock for a superpower's well-funded intelligence agency, but I think that
the threat model is not primarily about protecting against them.

I agree about the political part of the issue, but on the other hand, the
SHA-1 deprecation is one of the most proactive things the CA/Browser Forum has
done. Having it go not quite perfectly is still a vast improvement from
_reactively_ deprecating things only when they are fully insecure.

~~~
agwa
> Facebook's proposal is that only organizations that are a) demonstrably
> using this technique and b) validated at a higher level than automatic
> domain validation be allowed to get new SHA-1 certs

b) may help prevent collision attacks, but I have a hard time viewing a)
(requiring downgrade-proof cert switching) as anything but security theater.

Edit: it's not even clear to me that b) is an integral part of Facebook's
proposal. Their blog post says (emphasis added): "Such verification _can be
automated_ or manual, and appropriate measures can be put in place to reduce
the risk of a collision attack. Those protections _could_ include requiring LV
applicants to have already passed OV or EV verification"
[[https://www.facebook.com/notes/alex-stamos/the-
sha-1-sunset/...](https://www.facebook.com/notes/alex-stamos/the-
sha-1-sunset/10153782990367929)] CloudFlare's blog post
[[https://blog.cloudflare.com/sha-1-deprecation-no-browser-
lef...](https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-
behind/)] doesn't mention it at all.

~~~
geofft
Yeah, I agree that this should be manual, subject to significant checks, and
rare, and without that we've effectively extended the SHA-1 collision cutoff
date. (Another worthwhile check might be to require that it be an exact
renewal - same key and names - of an existing cert, signed before the
proposal.)

------
KenanSulayman
Well, you can just keep it plain-text if you're going to be using SHA1. So
don't worry about these people.

~~~
rmdoss
Not at all. Attacks against SHA1 on the HTTPS-context are really hard and
mostly not practical to pull it off.

------
justinsaccount
Every time the subject of obsolete or un-upgradeable devices comes up it is
pointed out that the people that buy these devices "don't care". They don't
care about android 6.0, they are happy with their $10 device running android
4.whatever that is vulnerable to who knows what.

So, probably not a popular opinion, but screw em. Maybe when they buy a
replacement device they will ask "Will this thing be obsolete in a year like
the last one or will it actually get software updates?" "Will I be able to
install a different ROM on this or is the bootloader locked?

~~~
colanderman
Ya that's a pretty hard judgement to make when _Google 's own devices_ aren't
even supported for more than one major version. Even the G1 didn't make it to
2.0.

------
0x0
Could the risk of SHA1 be mitigated by re-issuing certificates daily and
having 24 hours expiration dates? Or would any attacker be able to set
whatever they please for the expiration date if they find a collision?

------
mwsherman
This is a classic case of the perfect vs the good. The question is not whether
SHA1 is “acceptable”, but whether it is better than the alternative, which is
plain text for users that cannot do SHA256. It’s graceful degradation.

The number quoted of $70K to crack SHA1 indicates that it is non-trivial to
hack. Which means adversaries could break the encryption, but could only
afford to attack a small number of people. Which means that SHA1 is effective
for a large majority.

~~~
agwa
> Which means adversaries could break the encryption, but could only afford to
> attack a small number of people

No, because an attacker could forge a single CA certificate that could then be
used to sign certificates for an unlimited number of websites. This is what
the MD5 attack did: [https://www.win.tue.nl/hashclash/rogue-
ca/](https://www.win.tue.nl/hashclash/rogue-ca/)

~~~
makomk
That attack shouldn't work these days even if you can achieve a hash
collision. It requires the ability to predict the entire contents of the
certificate issued by the CA and I think CAs have since moved to using
unpredictable serial numbers in order to prevent this.

~~~
agwa
Alas, random serial numbers are only a "SHOULD" in the Baseline Requirements,
and not all CAs use them.

------
yuhong
I was proposing normal OV SHA1 certs, the key being to restrict to manual
issuance to reduce risk and to discourage use. The RapidSSL MD5 collision
attack was against automated DV cert issuing and would be obvious to people
manually processing CSRs.

------
DyslexicAtheist
the only interesting / relevant part of this article are the comments.

