Hacker News Reader

Comment by wwwigham | Hacker News Reader

I don't understand the rationale - SHA-1 gets sunset as broken crypto, indicating that with time a motivated attacker can find a collision and forge a cert for a SHA-1 secured site. Serving a SHA-1 cert to users whose browsers cannot understand newer cryptography seems like you'd be claiming that the security of those users' connections is not something you consider meaningful, as those users are still vulnerable to SHA-1 attacks. This just raises the barrier for entry to attack those users (compared to plaintext), except those users will potentially be unaware anything is wrong.

As the article states, 37 million visitors were using outdated crypto - that's 37 million potential sets of private information I could skim with a forged cert. Does protecting those users not matter?

View on HN

Cloudflare and others believe [1] the risk can be much reduced by new, carefully enforced issuing policies on the part of certificate authorities.

The vulnerability of SHA-1 isn't that it's feasible to generate an input that will produce a checksum of your choice - it's that it's feasible to generate two inputs that will produce the same checksum. This is orders of magnitude easier, due to the to the birthday problem [2].

The SHA-1 the certificate authority generates to sign isn't just for the private key in the certificate; it's also for metadata like the URL and the powers the certificate grants. So to successfully exploit the weakness of SHA-1 you not only have to find a collision between good and evil certs, you also have to get a CA to sign the good cert without fiddling with the metadata and hence changing the SHA-1.

The proposal is that CAs should start systematically adding a random serial number to every cert, i.e. always fiddling with the metadata, so it's impossible to choose the SHA-1 the CA will sign. So even if you find a collision, you won't be able to get a cert issued that lets you exploit it.

For example, maybe I know that sha1("the public key for good.example.com is asdfqwerzxcv and it isn't a CA") = sha1("the public key for evil.example.com is rtyufghjcvbn and it is a CA") = 7d97e98f8af710c7e7fe703abc8f639e0ee507c4 and if I ask a CA to sign the good cert they give me a signature for 7d97e98f8af710c7e7fe703abc8f639e0ee507c4 and I can copy the signature onto the evil cert. With this proposal, the CA would instead only agree to sign "the public key for good.example.com is asdfqwerzxcv and it isn't a CA, and the CA's random number is 994782906" and because I can't control the random number, I can't control the SHA1 of the cert they issue to me.

Unfortunately CAs have a poor track record of complying with their own issuing policies, so some people doubt CAs could be relied on not to mess this up.

[1] https://blog.cloudflare.com/why-its-harder-to-forge-a-sha-1-... [2] https://en.wikipedia.org/wiki/Birthday_problem

Protecting those users _does_ matter. As CloudFlare points out, many people simply cannot upgrade their devices to something that supports SHA2. Instead, the choice is either (1) they don't get crypto at all, because SHA2 won't work on their device, or (2) those users get SHA1, which is better than nothing. CloudFlare is advocating stance 2.

Or option 3 for truly important data: they don't get access at all. It would be inconvenient for that block of users, but it would avoid doing something that look s(to the end user) more secure than it is and lulling them into a false sense of security that means they don't see any need to upgrade.

Looking at the figures for who would get excluded (largest being 6%) that could sound pretty bad, but if that is a % of devices then it isn't so bad: most of them may be old mobile devices and people with them may have another machine (a laptop or desktop for instance) that they can access the functionality from.

Unfortunately for a commercial site excluding people, even just a fraction of a percent of them, this way might be something that is impossible to justify to the powers-that-be even with the "not wanting to enable people to do something insecure" argument.

If the site decides that the data is too valuable, they can probably ask CloudFlare to disable this feature for their site. If the user decides that the data is too valuable, they can decide not to access that data with vulnerable devices.

Correct. All our customers can disable SHA-1 fallback from our control panel. While a US-based bank, for instance, may decide it's better based on their risk assessment to not SHA-1, a Syrian-based refugee organization may reasonably have a different risk assessment and therefore decide to support it.

> but it would avoid doing something that look s(to the end user) more secure than it is and lulling them into a false sense of security that means they don't see any need to upgrade.

On that note, does CloudFlare still allow for https (cloudflare issued ssl) to http (on the backend)?

Is it feasible for websites to detect which cipher is being used and display a warning banner at the top of the page if SHA1 is used? (Similar to the cookie warnings most sites are now required to display to US visitors.)

Although maybe the precedent of serving content conditional on the cipher used might not be a good one to set.

With the push for HTTPS everywhere, those old devices won't get content at all.

Case 1) isn't that they access the site in plaintext, but that they don't get access at all. Case 2) could easily be that their credit card gets emptied.

Besides what others have pointed out, there's also the economic angle. It may be worth the estimated $X (for whatever value of $X you believe) to predict a collision, forge a cert, and MITM all of a website's traffic. It may not be worth nearly as much if the prize is only the ability to MITM 2% of that website's traffic. Maybe it's 6% under oppressive regimes, but it's still the same amount of work for a much smaller prize.

Of course we'd like to protect all 100%, but this is about tradeoffs. Assuming downgrade attacks are as preventable as they claim, I think it's respectable that they're making this kind of effort to reduce the impact.

In addition to what sister comments said, it's also a matter of your threat model. While SHA-1 might no longer be sufficient protection against targeted attacks by powerful attackers, it's still good enough to protect against a random person snooping on another random person on an open WiFi network.

Reply on news.ycombinator.com