On Thu, 3 Nov 2016 17:53:01 +0000 Gervase Markham <g...@mozilla.org> wrote:
> On 28/10/16 16:11, Patrick Figel wrote: > > I found a number of SHA-1 certificates chaining up to CAs trusted by > > Mozilla that have not been brought up on this list or on Bugzilla > > yet. > > Using the handy crt.sh link posted by Rob, I have gone through the > 2016 SHA-1 issuances known to crt.sh to filter out those which chain > up to a root trusted by Mozilla. (Handily, crt.sh contains this > information as well.) There are a distressingly large number of > them :-( > > Based on Patrick's report, I filed: > https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 (Gov of Spain) > https://bugzilla.mozilla.org/show_bug.cgi?id=1313872 (DigiCert) > https://bugzilla.mozilla.org/show_bug.cgi?id=1313873 (DocuSign) > > and based on this additional research, I have filed: > https://bugzilla.mozilla.org/show_bug.cgi?id=1315019 (TeliaSonera) > https://bugzilla.mozilla.org/show_bug.cgi?id=1315016 (Visa) > https://bugzilla.mozilla.org/show_bug.cgi?id=1315018 (GlobalSign) > https://bugzilla.mozilla.org/show_bug.cgi?id=1315035 (T-Systems) > > There may be more in the future. I would be interested in the group's > opinion on what to do about: > > A) SHA-1 precerts with no actual cert logged (1 CA) This is just as bad as signing an actual cert with SHA-1. RFC6962 says: "The signature on the TBSCertificate indicates the certificate authority's intent to issue a certificate. This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate)." This is not just a theoretical concern. When this came up earlier this year with Symantec, I explained that pre-certificates are a vector for exploiting a SHA-1 collision, since the forged/collided certificate need not contain the pre-certificate poison extension. > B) SHA-1 email certificates with no DNS names, although their lack of > an EKU means they are valid for server auth (2 CAs) The more pertinent question is the issuing CA's EKU. > C) SHA-1 email certificates with EKU but no serverAuth (1 CA) Ditto. > D) Small numbers (1 or 2) of SHA-1 certs issued in early January. One > could perhaps charitably say that the CA or their subCA made a > mistake, realised, has fixed it, and hasn't made it since. Now it's > November, is this worth chasing? (4 CAs) > > Also, does it make it better if the CA has already revoked the > certificate before we report it to them? No. Revocation doesn't help because the forged/collided cert need not share the same serial number. Revocation would only help if it were based on the SHA-1 hash of the TBSCertificate. The common thread in all of these answers is that the forged/collided certificate need not look anything like the data that the CA signed with SHA-1. Any time a CA trusted for serverAuth signs attacker-controlled data using SHA-1 there is a risk of a forged serverAuth certificate. Regards, Andrew _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
