Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
CA/Symantec Issues: Difference between revisions
Jump to navigation
Jump to search
Add info from latest Symantec communication
(Update list of problems and dates) |
(Add info from latest Symantec communication) |
||
| Line 1: | Line 1: | ||
This page lists all confirmed | This page lists all confirmed issues involving the CA "Symantec". It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, email [mailto:gerv@mozilla.org Gerv]. Information here is correct to the best of Mozilla's knowledge and belief. Symantec has also [https://bug1334377.bmoattachments.org/attachment.cgi?id=8867735 confirmed] the accuracy of the information, although errors transcribing their statements into this page remain Mozilla's. | ||
The issues are in broadly chronological order by end date. | The issues are in broadly chronological order by end date. | ||
| Line 28: | Line 28: | ||
The inclusion of a BR-compliant OID in a non-BR cert was disappointing, but can be accepted as an oversight. | The inclusion of a BR-compliant OID in a non-BR cert was disappointing, but can be accepted as an oversight. | ||
==Issue C: Unauthorized EV Issuance by RAs (January 2014 - February 2015)== | |||
Symantec have [https://bug1334377.bmoattachments.org/attachment.cgi?id=8867735 stated] that their four RA partners (CrossCert, CertSuperior, Certisign and Certisur) had the technical ability to issue EV certificates despite not having EV audits for their operations. Symantec does not directly state so, but it is assumed that, given the lack of audits and the infrequency of occurrence (normal process was for them to pass EV request information on to Symantec) that the RAs were not authorized to make such issuances. However, three of those organizations did so on a number of occasions. Looking at the dates, this appears to have happened in two successive audit periods. | |||
===Symantec Response=== | |||
Symantec says that they revalidated the EV information used to issue the certs once they discovered the issuance, and that the validations met the EV authentication guidelines. However, it seems that they did not implement technical measures to prevent further occurrences. Symantec discovered all this before the recent investigation, but did not disclose these events to Mozilla as misissuances at the time. | |||
===Further Comments and Conclusion=== | |||
EV issuance is a trusted privilege; Symantec should not have made it possible for organizations without the appropriate audits to issue EV, and they should have stopped them after it happened. | |||
==Issue D: Test Certificate Misissuance (April 2009 - September 2015)== | ==Issue D: Test Certificate Misissuance (April 2009 - September 2015)== | ||
| Line 125: | Line 137: | ||
It is concerning that their first experience with SHA-1 misissuance did not cause them to analyse their systems and find this potential problem, or to put in place SHA-1 blocks in enough places to catch this. | It is concerning that their first experience with SHA-1 misissuance did not cause them to analyse their systems and find this potential problem, or to put in place SHA-1 blocks in enough places to catch this. | ||
==Issue L: Cross-Signing the US Federal Bridge ( | ==Issue L: Cross-Signing the US Federal Bridge (2009 - July 2016)== | ||
The US Government has an [https://fpki-graph.fpki-lab.gov extremely complicated] PKI called the Federal PKI. It has [https://bugzilla.mozilla.org/show_bug.cgi?id=478418 applied for inclusion] in the Mozilla root store but that application seemed unlikely ever to be successful due to the difficulty of bringing the entire FPKI in line with Mozilla's policies. During the period in question, it had a number of non-audited subordinate CAs. | The US Government has an [https://fpki-graph.fpki-lab.gov extremely complicated] PKI called the Federal PKI. It has [https://bugzilla.mozilla.org/show_bug.cgi?id=478418 applied for inclusion] in the Mozilla root store but that application seemed unlikely ever to be successful due to the difficulty of bringing the entire FPKI in line with Mozilla's policies. During the period in question, it had a number of non-audited subordinate CAs. | ||
Since | Since 2009, Symantec has regularly had a valid cross-sign for one or both of "[https://crt.sh/?caid=1324 Federal Bridge CA]" and "[https://crt.sh/?caid=1410 Federal Bridge CA 2013]", which are both part of the FPKI, thereby making (as far as I can tell) all certificates in the FPKI be publicly trusted, and technically making Symantec responsible to Mozilla for all certificates issued in the FPKI, including any BR violations. The intermediate CA certificate(s) concerned were not disclosed in the CCADB, as Mozilla practice at the time required. This was [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/PGhVbV-UBQAJ reported in m.d.s.policy]. | ||
Symantec is not the only CA to have done this; IdenTrust [https://crt.sh/?id=9114292 also did it on multiple occasions] from 2011-01-14 onwards. I don't believe there are any unexpired unrevoked (by OneCRL) links between the FPKI and the Mozilla trust store any more, via any CA. | Symantec is not the only CA to have done this; IdenTrust [https://crt.sh/?id=9114292 also did it on multiple occasions] from 2011-01-14 onwards. I don't believe there are any unexpired unrevoked (by OneCRL) links between the FPKI and the Mozilla trust store any more, via any CA. | ||
| Line 143: | Line 155: | ||
===Further Comments and Conclusions=== | ===Further Comments and Conclusions=== | ||
Symantec [https://bug1334377.bmoattachments.org/attachment.cgi?id=8867735 state] that they were aware of the issues with this cross-signing since 2014 and were investigating whether it was actually required. It would seem it took two years to figure that out, and at no time was Mozilla informed about the fact that Symantec was enabling public trust for the entire Federal PKI. | |||
While technical controls within the FPKI may have prevented it, Symantec had no way of knowing or controlling whether the FPKI was issuing EV certificates using Symantec's OID. | |||
==Issue N: Premature Manual Signing Using SHA-1 (July 2016)== | ==Issue N: Premature Manual Signing Using SHA-1 (July 2016)== | ||
| Line 214: | Line 222: | ||
* Test certs to registered domains: Discovered and fixed in Sep 2015, but "while inappropriate use of registered domains for testing stopped during the course of our 2014-2015 audits, we did not complete the ID and revocation of all certificates until Mar 2016, and so the finding remained in our first-half Dec 1, 2015-Jun 15, 2016 audits." | * Test certs to registered domains: Discovered and fixed in Sep 2015, but "while inappropriate use of registered domains for testing stopped during the course of our 2014-2015 audits, we did not complete the ID and revocation of all certificates until Mar 2016, and so the finding remained in our first-half Dec 1, 2015-Jun 15, 2016 audits." | ||
* Test certs to un-registered domains: Discovered and fixed in October 2015, but there was a "discovery of additional instance involving approved domains in a test account resulting in 6 additional issued certificates in Approximately Mar 2016." | * Test certs to un-registered domains: Discovered and fixed in October 2015, but there was a "discovery of additional instance involving approved domains in a test account resulting in 6 additional issued certificates in Approximately Mar 2016." | ||
* Unauthorized employees with access to certificate issuance capability: discovered in September 2015, last problem of this type remediated in June 2016 after extensive security review. | * Unauthorized employees with access to certificate issuance capability: discovered in September 2015, last problem of this type remediated in June 2016 after extensive security review. | ||
* Failure to maintain physical security records for 7 years: discovered and fixed in January 2016. | * Failure to maintain physical security records for 7 years: discovered and fixed in January 2016. | ||
| Line 224: | Line 232: | ||
===Additional Comments and Conclusion=== | ===Additional Comments and Conclusion=== | ||
It is noteworthy that even if third party audits are qualified, that does not lead to a qualification on Symantec's main audit. | |||
==STRUCK: <strike>Issue R: Insecure Issuance API (2013 or earlier - November 2016)</strike>== | ==STRUCK: <strike>Issue R: Insecure Issuance API (2013 or earlier - November 2016)</strike>== | ||
| Line 271: | Line 277: | ||
The Baseline Requirements, in section 4.9.1.1 item 9, state that the CA SHALL revoke a certificate if "The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement". However, Symantec did not revoke all the certificates. | The Baseline Requirements, in section 4.9.1.1 item 9, state that the CA SHALL revoke a certificate if "The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement". However, Symantec did not revoke all the certificates. | ||
Instead, Symantec decided to shut down the RA program entirely and re-assess every certificate issued under it. Symantec committed to revalidating all of the CrossCert-issued certificates (10,000+) and any of the 20,000+ certificates issued by their other RAs if deficient validation was discovered. However, the determination of deficient validation was made based on the RAs own logs of activity, which may themselves be suspect given some of the audit deficiencies found at these RAs. | Instead, Symantec decided to shut down the RA program entirely and re-assess every certificate issued under it. Symantec committed to revalidating all of the CrossCert-issued certificates (10,000+) and any of the 20,000+ certificates issued by their other RAs if deficient validation was discovered. However, the determination of deficient validation (in cases other than CrossCert) was made based on the RAs own logs of activity, which may themselves be suspect given some of the audit deficiencies found at these RAs. | ||
Symantec has produced a [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/dVMxrUVygS0 further, long account] of the situation. It confirms that, while there were multiple systems designed to teach the RAs what to do, the only system which checked that they were actually doing it (and which Symantec paid attention to) were the WebTrust audits. They disagree that full revocation of all certs is a proportionate response. | Symantec has produced a [https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/dVMxrUVygS0 further, long account] of the situation. It confirms that, while there were multiple systems designed to teach the RAs what to do, the only system which checked that they were actually doing it (and which Symantec paid attention to) were the WebTrust audits. They disagree that full revocation of all certs is a proportionate response. | ||
| Line 370: | Line 376: | ||
==Issue Y: Under-audited or Unaudited Unconstrained Intermediates (December 2015 - April 2017)== | ==Issue Y: Under-audited or Unaudited Unconstrained Intermediates (December 2015 - April 2017)== | ||
Two intermediate CAs, which are subordinates of or cross-certified by VeriSign Universal Root Certification Authority, have audit and control problems: | Two intermediate CAs, which are subordinates of or cross-certified by VeriSign Universal Root Certification Authority (which is EV-enabled), have audit and control problems: | ||
* [https://crt.sh/?Identity=%25&iCAID=1384&exclude=expired VeriSign Class 3 SSP Intermediate CA - G2] | * [https://crt.sh/?Identity=%25&iCAID=1384&exclude=expired VeriSign Class 3 SSP Intermediate CA - G2] | ||
| Line 387: | Line 393: | ||
===Symantec Response=== | ===Symantec Response=== | ||
Symantec | Symantec say that the subCAs under these intermediates are under Symantec's control and, in all cases but one, are technically prevented from issuing for TLS server authentication. In one case, a customer does have the ability to issue TLS server auth certificates. The subCAs concerned ("CSC Device CA – G2" and "CSRA FBCA C3 Device CA"), like all the others, do not have BR audits. | ||
They say that their technical controls, which apply to all these subCAs, prevent EV issuance. | |||
Nevertheless, they plan to privatise this bit of the PKI by revoking trust in the certificates which link it to the WebPKI on May 24th, 2017. | |||
===Further Comments and Conclusions=== | ===Further Comments and Conclusions=== | ||
Symantec say that these hierarchies were not BR audited based on the system controls they have in place and the intended usage. But Mozilla policy is based on capability, not intent. And in one case, both capability and intent led to the issuance of TLS server certs, and yet no audit was obtained. | |||