Update language to emphasize that core goal is allowing SHA-1 to be deprecated

[konklone]

@schoen kindly emailed me to make sure I knew, and the site conveyed, that the dangers of SHA-1 won't be gone -- even for site owners that upgrade to SHA-2 -- until SHA-1 is widely deprecated and untrusted by exploitable systems. With his permission, I've included his email here:

I think, as with a lot of cert-related things, it's tricky to convey to people that their site is at risk from certificate system security failures even if their site did everything right. In this case, a successful collision attack allows the attacker to generate a valid cert for an arbitrary site, whether or not that site is using SHA-1 (just as the MD5 collision attack let the researchers make a fake MD5 cert for any site of their choice, regardless of whether that site was using MD5 for its legitimate cert).

Therefore, there is no heightened risk to users of sites that are using SHA-1 certs, nor is there a reduced risk to users of sites that are using SHA-256 (except in some pinning scenarios, maybe). If awesome.com adopts a SHA-256 cert today and retro.com still has an old MD5 cert, an attacker who can generate SHA-1 collisions can make a new fake cert for either domain just as readily, and using exactly the same attack procedure!

To which I asked: "How can an attacker who can generate SHA-1 collisions make a fake cert for a cite using SHA-256? And if that's true, how does updating to SHA-256 help anybody?"

@schoen replied:

Take a look at the analogy of MD5, the previous obsolete hash algorithm
used to generate digital certificates.

http://www.win.tue.nl/hashclash/rogue-ca/

There, the attacker would generate two certificates whose content had the same MD5 value. One certificate might be for legitimate.org (which the attacker had registered), while another certificate might be for victim.com (which belongs to a third party). Because the certificates' content has the same MD5 value, if a CA signs that MD5 value, it is effectively signing both certificates (in the sense that a browser can't tell that the attacker is lying if the attacker presents the CA's signature together with the victim.com certificate instead of the legitimate.org certificate). The CA doesn't realize that it's signing the victim.com certificate because it never sees that certificate and doesn't even know that it exists.

The effectiveness of that attack doesn't depend on what kind of certificate victim.com already has (if any) or on any of the algorithms that were intentionally used by victim.com. Even if victim.com was using SHA-256 for its cert (issued by AwesomeCA Ltd., let's say), the attacker can still get some other CA (Ancient Algorithms, Inc.?) to issue the colliding MD5 cert that refers to victim.com, and then use that cert in an attack.

The same kinds of risks then apply to SHA-1, if we think that the same kinds of attacks will be feasible against SHA-1 that were feasible against MD5.

So the benefit of upgrading is (as you describe it correctly on the site) that people who are trying to phase out the old algorithms can actually do so. If everybody or most everybody upgrades, then certs that use the old algorithms look suspicious (and eventually people can stop accepting them, or stop accepting some of them in particular contexts). If nobody or few people upgrade, then there's no way to distinguish between a legitimate cert with an old algorithm and a fake cert with an old algorithm. You could think of this as an ecosystemic benefit rather than a benefit to each individual site that upgrades its cert.

There are some cases in which you can maybe get an individual site benefit, having to do with cert pinning, where you try to stop other people from accepting some purported certs for your domain if the provenance of those certs is not what you expect. I guess most site operators don't currently use those mechanisms, though.

I'll update the copy to make this point more clear, and to link to http://www.win.tue.nl/hashclash/rogue-ca/, which is an excellent depiction of the problem.

[konklone]

I've updated the copy in a03b28a and deployed it to the site. Thanks for the suggestions, @schoen.