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
