Hacker News Reader

Comment by vaadu | Hacker News Reader

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

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.

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

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.

> 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/...] CloudFlare's blog post [https://blog.cloudflare.com/sha-1-deprecation-no-browser-lef...] doesn't mention it at all.

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.)

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

Alas, we already more or less live in this world. If old standards were burned down without remorse more regularly, I'd think we'd see many things done differently. "But think of the pacemaker in the children's hospital" has unfortunately been the order of the day for quite some time.

Ah, but SHA-1 certs are actually being deprecated for publicly-trusted roots. Symantec wanted to push the deadline back because of their "very large enterprise customers" who had legacy clients, and they didn't get it. I don't think the Facebook/CloudFlare proposal is going to fly either.

Of course there will still be heaps of SHA-1 out there from private roots, but at least the rest of the world can move forward.

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

It means people can keep using their insecure clients instead of being forced to upgrade to something secure.

Facebook's user base as of January 2014 was at 1.24B monthly users[1]. According to FB's post, up to 7% of their users do not support SHA2 certs. This would mean approximately 86.8m FB users alone would affected by full-stop SHA1 degradation. I'm happy to see FB has implemented a mechanism selective cert selection and other organizations that care about their user's security ought to look at them for a model on how to approach this methodically.

SHA1 isn't great, but it is certainly better than plaintext communications.

[1] http://thenextweb.com/facebook/2014/01/29/facebook-passes-1-...

If it's broken (which it is), it is no better than plaintext.

It isn't _completely_ broken. That is why FB is still advocating for a two tiered approach (SHA2 when possible, SHA1 everywhere else). SHA1 hash collisions are indeed now within the range of well funded governments, but it is not within the range of your average script kiddie to find possible collisions. To prove my point, I'd ask you to find an arbitrary Root CA cert which uses SHA1 hash and attempt to clone it. I think you'll find that this takes still a considerable amount of effort and/or it is completely out of reach.

I should be clear that SHA1 shouldn't be used for cryptographic purposes that require high amount of trust, but for your average everyday FB status updates it is probably fine when coupled with other protections.

I'm personally on your side of the argument and against Facebook's stance, but this statement is strictly speaking not true. At worst, it will be equivalent to protection provided by an encryption scheme without authenticating the other party and it defeats passive attackers. That's not quite as bad as sending plaintext (in practice, it is much much better when it applies to the internet broadly: cf. firesheep).

P.S. that's basically the state of SMTP encryption, which is quite sad.

Agreed. At least if things break noisily then the user will have an idea that things are now different. If you silently fall back with no feedback to the user then they may never know that they should have lessened security expectations.

Reply on news.ycombinator.com