3 ms·
> 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
by agwa 11y ago
> 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 11y agoFacebook'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 11y ago> 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/10153782990367929 https://www.facebook.com/notes/alex-stamos/the-sha-1-sunset/...] CloudFlare's blog post [https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-behind/ https://blog.cloudflare.com/sha-1-deprecation-no-browser-lef...] doesn't mention it at all.
- geofft 11y agoYeah, 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.)
- tedunangst 11y ago> 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.
- agwa 11y agoAh, 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.