Update number 2: I worked on this for a bit, and found that there are a number of cascading dependencies on the old-style MD5+SHA1 hashes, and it would have taken a long time to change them all. Peter and I wound up calculating our own MD5 hash using Firefox's nsICryptoHash, in https://github.com/EFForg/https-everywhere/pull/796.
On 01/15/2015 12:46 PM, Jacob Hoffman-Andrews wrote: > Update on this: Peter pointed out that we also rely on this hashing for > X509ChainWhitelist.js, where a hash collision *is* security relevant > because it could cause a bogus certificate to not be submitted to the > SSL Observatory. However, we both think that SHA256 alone is > sufficiently strong against collisions, so we're going to move to that, > and abandon the hash-concatenation scheme. > > On 01/12/2015 03:55 PM, Jacob Hoffman-Andrews wrote: >> In the SSL Observatory, we try to check whether a certificate chains to >> a private root certificate before submitting it, in order to avoid >> publicizing non-public hostnames. In order to do so, we embed a list of >> hashes of public root certificates. If an observed cert chains to a root >> whose hash is in the list, we submit it. Otherwise, we hold it back >> (depending on a setting). >> >> In the past, this list of public root certificate hashes used a >> composite hash, where SHA1 and MD5 output were concatenated. I think >> this was theoretically to protect against a hash breakage, since an >> attacker who is able to forge certificates is likely to be doing so >> through a hash collision attack. But the idea is that it's less likely >> for an attacker to have a simultaneous collision against both SHA1 and MD5. >> >> Per https://github.com/EFForg/https-everywhere/pull/885, this list is >> currently broken because firefox removed the md5Fingerprint attribute on >> certs. That's fine, it was time to move on from MD5 anyhow. For now I've >> got the list using just SHA1. >> >> I intended to re-generate with a composite hash of SHA1 and SHA256, on >> the same principle. However, on further thought it seems like the idea >> is wrong. An attacker would not try to make a bogus root collide with >> the known public roots, since that would ensure submission. The attacker >> would want to make their bogus chain look like it was signed by a >> private cert, so it would not get submitted. >> >> So, I propose that the strength of the hashes in Root-CAs.js does not >> matter, and we should continue with only a SHA1 hash. Thoughts? >> >> Thanks to Seth for raising some questions about whether composite hash >> is needed. >> >> Jacob >> > _______________________________________________ > HTTPS-Everywhere mailing list > [email protected] > https://lists.eff.org/mailman/listinfo/https-everywhere > _______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
