[HTTPS-Everywhere] Hashing for SSL Observatory root cert list

[Jacob Hoffman-Andrews]

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
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere
>