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
Further expansion
(Further updates) |
(Further expansion) |
||
| Line 2: | Line 2: | ||
This page lists all confirmed or suspected issues involving the CA "Symantec". It will be 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]. | This page lists all confirmed or suspected issues involving the CA "Symantec". It will be 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. Note that Symantec has not yet had a chance to respond to some of the issues presented here, and so we expect this information will be updated over time. | |||
The issues are in broadly chronological order by end date. | The issues are in broadly chronological order by end date. | ||
==Issue XXX: Certificate Issued Directly From Root (Dec 2013 - Jan 2014)== | ==Issue XXX: 1024-bit Certificate Issued Directly From Root (Dec 2013 - Jan 2014)== | ||
Symantec issued a cert to one of its customers, Pitney Bowes, that did not comply with at least two provisions of the CA/Browser Forum Baseline Requirements, in that it was issued directly from a root, and that it was a 1024-bit cert which expired after the end of 2013. Symantec believed this was the only technical way to ensure continuity of service for the customer concerned. | |||
This cert was also backdated, but that is not a BR or Mozilla policy violation, as long as it was not done to evade a technical control. It also has a short serial number. Entropy in the serial number is a SHOULD in the relevant version of the BRs (1.1.6). 20 bits of entropy is a MUST in the Mozilla policy (2.2), but it doesn't say it has to be in the serial number - it could be that they randomised the notBefore time. I am told Microsoft removed the allowance for doing entropy in the Date field on 11th November 2013, so this was a violation of their policies XXXURL. | |||
The incident is recorded in {{bug|966350}}. | |||
Symantec | ===Symantec Response=== | ||
Symantec self-reported this issuance to Mozilla at the end of January 2014. | |||
===Further Comments and Conclusion=== | |||
Symantec disclosed | Symantec did not request permission to issue in advance, they disclosed the issuance at least a month after it had happened, and the replacement certificate (unlike the original) asserted a "BR Compliant" OID. | ||
==Issue XXX: Test Certificate Misissuance (April 2009 - September 2015)== | ==Issue XXX: Test Certificate Misissuance (April 2009 - September 2015)== | ||
Between 2009 and 2015, Symantec issued a large number of test certificates in their publicly trusted hierarchies. These contained domains that Symantec did not own or control, and for which domain validation was not performed. Some of these domains were unregistered, and others were owned by other organizations. The registered domains used included those belonging to Google | Between 2009 and 2015, Symantec issued a large number of test certificates in their publicly trusted hierarchies. These contained domains that Symantec did not own or control, and for which domain validation was not performed. Some of these domains were unregistered, and others were owned by other organizations. The registered domains used included those belonging to Google and Opera Software. Some of the test certificates left Symantec's network because they were logged in CT; Symantec claims no others did. However, Symantec personnel would have had access to the public and private keys of the certs. | ||
Some details of this incident are recorded in {{bug|1214321}}. | |||
===Symantec Response=== | |||
It took quite a while for the full scale of the problem to emerge, and Symantec had to publish numerous updates to their "Final Report". Symantec released a number of documents relating to this - [https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report.pdf Final Report], [https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_12_2015.pdf Final Report v2], [https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3.pdf Final Report v3], [https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf list of certs containing owned domains], [https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregisteredv2.pdf list of certs containing unregistered domains], [https://www.symantec.com/page.jsp?id=test-certs-update further update]. They also issued a blog post, "[http://archive.is/Ro70U A Tough Day As Leaders]", which is no longer on their website but has been archived. It indicates that 3 employees were fired as a result of the misissuance. | |||
==Issue XXX: Audit Issues For Symantec Itself (December 2014 - November 2015)== | |||
The [https://www.symantec.com/content/en/us/about/media/repository/GeoTrust-WTBR-2015.pdf most recent available audit] for Symantec's GeoTrust roots runs from December 1st, 2014 to November 30th, 2015. The newer one should be available by now, but seems to have been delayed. On pages 2-5 of that audit, the management assertions (and thereby the auditors) call out the following violations of the Baseline Requirements or Network Security Guidelines: | |||
# Issuance of Internal Server Names | |||
# Test certificates issued for domains Symantec did not own or control (see above) | |||
# No audit report, or invalid audit report, obtained for 3 of 5 external partner sub-CAs | |||
# Failure to maintain physical security records for an appropriate period of time | |||
# Unauthorized employees with access to certificate issuance capability | |||
# Failure to review application and system logs | |||
The [https://www.symantec.com/content/en/us/about/media/repository/Symantec-STN-WTCA-2015.pdf most recent available audit] for Symantec's Verisign and own-brand roots runs from December 1st, 2014 to November 30th, 2015. The newer one should be available by now, but seems to have been delayed. On pages 2-3 of that audit, the management assertions (and thereby the auditors) call out the following violations of the Baseline Requirements or Network Security Guidelines: | |||
# Background checks not renewed for trusted personnel | |||
# Unauthorized employees with access to certificate issuance capability | |||
# Failure to maintain physical security records for an appropriate period of time | |||
# Test certificates issued for domains Symantec did not own or control (see above) | |||
===Symantec Response=== | |||
XXXComment from Kathleen | |||
==Issue XXX: SHA-1 Issuance After Deadline (January 2016)== | ==Issue XXX: SHA-1 Issuance After Deadline (January 2016)== | ||
Symantec issued five SHA-1 certificates after the SHA-1 issuance deadline. These were certificates requested (or enrolled) in 2015 but issued in 2016. Symantec [https://cabforum.org/pipermail/public/2016-January/006519.html reported this issue] to the CAB Forum public mailing list. | Symantec issued five SHA-1 certificates after the SHA-1 issuance deadline. These were certificates requested (or enrolled) in 2015 but issued in 2016. | ||
===Symantec Response=== | |||
Symantec [https://cabforum.org/pipermail/public/2016-January/006519.html self-reported this issue] to the CAB Forum public mailing list. | |||
===Further Comments and Conclusion=== | |||
Symantec were not the only CA to have similar issues with accidental SHA-1 issuance. This issue is listed here because it was not the only time it happened (see below). | |||
==Issue XXX: SHA-1 Issuance After Deadline, Again (February 2016)== | ==Issue XXX: SHA-1 Issuance After Deadline, Again (February 2016)== | ||
Symantec issued a [https://crt.sh/?id=13407116&opt=cablint SHA-1 CT precertificate] in February 2016. They then seemed to claim | Symantec issued a [https://crt.sh/?id=13407116&opt=cablint SHA-1 CT precertificate] in February 2016. They then seemed to claim that misissuance of a pre-certificate is not misissuance. (The CT RFC states that issuance of a pre-certificate is considered equivalent to issuance of the certificate, and so Mozilla considers that pre-certificate misissuance is misissuance.) | ||
===Symantec Response=== | |||
Their explanation for the incident was as follows: | |||
<blockquote> | <blockquote> | ||
| Line 35: | Line 79: | ||
</blockquote> | </blockquote> | ||
It is concerning that their first experience with SHA-1 misissuance did not cause them to analyse their systems and find this potential problem. | ===Further Comments and Conclusion=== | ||
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 XXX: Cross-Signing the US Federal Bridge (December 2015 - July 2016)== | |||
The US Government has an 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. At the time of this incident, it had a number of non-audited subordinate CAs. | |||
Presumably in November or December of 2015, Symantec [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/PGhVbV-UBQAJ cross-signed] one of the root CAs in the FPKI ("Federal Bridge CA 2013"), thereby making certificates below that root in the chain of trust be publicly trusted, and technically making Symantec responsible to Mozilla for all certificates issued in the covered part of the FPKI, including any BR violations. The [https://crt.sh/?id=12638543 intermediate CA certificate concerned] was not disclosed in the CCADB, as Mozilla practice at the time required. | |||
Symantec | ===Symantec Response=== | ||
When this was drawn to their attention, Symantec [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/OAJD-tWBAAAJ did not revoke] the cross-sign, instead allowing it to expire (less than a month later). | |||
==Issue XXX: Premature Manual Signing Using SHA-1 (July 2016)== | ==Issue XXX: Premature Manual Signing Using SHA-1 (July 2016)== | ||
Symantec applied to the root programs for leave to issue SHA-1 certificates for a customer. As part of that process, they planned to prepare tbsCertificates ("To Be Signed Certificates" - all the data except for the signature) for CAB Forum review. However, they [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/VjRDU_VAOf8/r8xhGtUWAgAJ | Symantec applied to the root programs for leave to issue SHA-1 certificates for a customer. As part of that process, they planned to prepare tbsCertificates ("To Be Signed Certificates" - all the data except for the signature) for CAB Forum review. However, they accidentally issued real certificates - i.e. they signed the tbsCertificate data using SHA-1. This was supposedly a manual process but it seems like the relevant instructions were either deficient (in that they specified too many steps) or not followed. | ||
===Symantec Response=== | |||
Symantec [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/VjRDU_VAOf8/r8xhGtUWAgAJ self-reported] this issue to Mozilla. Their remediation was to revoke all of those certificates, and issue new ones after permission was granted. | |||
==Issue XXX: UniCredit Sub CA Failing To Follow BRs (April - October 2016)== | ==Issue XXX: UniCredit Sub CA Failing To Follow BRs (April - October 2016)== | ||
Symantec issued an unconstrained sub-CA to a company called UniCredit. This company persistently issued certificates which were BR-noncompliant (e.g. missing SANs, missing OCSP URIs). During this time, they did not have the appropriate audits and Symantec were aware of this. Symantec [https://mozillacaprogram.secure.force.com/Communications/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004 claimed], in response to the CA Communication of March 2016, that they had disclosed to Mozilla all their intermediate CAs along with audits, but this was not true in the case of UniCredit. The [http://ca.unicredit.eu/CPS/cps.html UniCredit CPS] was also BR-noncompliant, in that it said that SANs were optional. | Symantec issued an unconstrained sub-CA to a company called UniCredit. This company persistently issued certificates which were BR-noncompliant (e.g. missing SANs, missing OCSP URIs). During this time, they did not have the appropriate audits and Symantec were aware of this. Symantec [https://mozillacaprogram.secure.force.com/Communications/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00004 claimed], in response to the CA Communication of March 2016, that they had disclosed to Mozilla all their intermediate CAs along with audits, but this was not true in the case of UniCredit. The [http://ca.unicredit.eu/CPS/cps.html UniCredit CPS] was also BR-noncompliant, in that it said that SANs were optional. | ||
This incident is recorded in {{bug|1261919}}. | |||
===Symantec Response=== | |||
Several months after this problem was discovered by Mozilla, Symantec eventually ordered them to stop issuing, but they continued, in violation of that agreement. Symantec then finally revoked their intermediate. | Several months after this problem was discovered by Mozilla, Symantec eventually ordered them to stop issuing, but they continued, in violation of that agreement. Symantec then finally revoked their intermediate. | ||
==Issue XXX: Insecure Issuance API (2013 or earlier - November 2016)== | ==Issue XXX: Insecure Issuance API (2013 or earlier - November 2016)== | ||
According to [https://www.facebook.com/cbyrneiv/posts/10155129935452436 a report], for several years Symantec operated an issuance API which was insufficiently secure, such that URL parameter substitution attacks would allow one customer to view, reissue, revoke and otherwise control certificates (including non-server certs) belonging to another customer. When made aware of these issues, Symantec took a very long time to fix them, and they may not have been fully fixed at the time Symantec terminated its RA program entirely. | According to [https://www.facebook.com/cbyrneiv/posts/10155129935452436 a report], for several years Symantec operated an issuance API which was insufficiently secure, such that URL parameter substitution attacks would allow one customer to view, reissue, revoke and otherwise control certificates (including non-server certs) belonging to another customer. When made aware of these issues, Symantec took a very long time to fix them, and they may not have been fully fixed at the time Symantec terminated its RA program entirely. | ||
===Symantec Response=== | |||
Symantec has not yet been formally asked by Mozilla to respond to this issue. However, they commented [http://www.csoonline.com/article/3184897/security/api-flaws-said-to-have-left-symantec-ssl-certificates-vulnerable-to-compromise.html to the press]: | Symantec has not yet been formally asked by Mozilla to respond to this issue. However, they commented [http://www.csoonline.com/article/3184897/security/api-flaws-said-to-have-left-symantec-ssl-certificates-vulnerable-to-compromise.html to the press]: | ||
| Line 69: | Line 127: | ||
For several years, Symantec operated an RA (Registration Authority) program. The companies in this program had independent authority to issue certificates under Symantec intermediates, and those certificates were not specifically marked to say that a particular RA had issued them instead of Symantec directly. This by itself is not against any existing policy. | For several years, Symantec operated an RA (Registration Authority) program. The companies in this program had independent authority to issue certificates under Symantec intermediates, and those certificates were not specifically marked to say that a particular RA had issued them instead of Symantec directly. This by itself is not against any existing policy. | ||
However, In January 2017, [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ it was discovered] that a small number of certificates had been misissued using Symantec intermediates by an RA called CrossCert in Korea. The investigation of these matters led to increasing further discoveries of misissuances (totalling 127 confirmed cases) and potential misissuances by CrossCert, together with poor CA practice by them and other companies in Symantec's RA network | However, In January 2017, [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ it was discovered] that a small number of certificates had been misissued using Symantec intermediates by an RA called CrossCert in Korea. The investigation of these matters led to increasing further discoveries of misissuances (totalling 127 confirmed cases) and potential misissuances by CrossCert, together with poor CA practice by them and other companies in Symantec's RA network. This issue deals with the certificate misissuances; the following issue deals with the audit-related problems uncovered. | ||
Types of misissuance by CrossCert: | Types of misissuance by CrossCert: | ||
| Line 80: | Line 138: | ||
Some of these misissuance were caused by employees of the RA CrossCert overriding compliance flags in Symantec's issuance system. Symantec had no process in place to review the logs of overridden flags. For some of the certs, they contained domains neither Symantec nor CrossCert own or control, and CrossCert did not complete the appropriate domain validations for them. | Some of these misissuance were caused by employees of the RA CrossCert overriding compliance flags in Symantec's issuance system. Symantec had no process in place to review the logs of overridden flags. For some of the certs, they contained domains neither Symantec nor CrossCert own or control, and CrossCert did not complete the appropriate domain validations for them. | ||
This incident is recorded in {{bug|1334377}}. | |||
===Symantec Response=== | |||
Due to these discoveries, Symantec subsequently decided to shut down the RA program entirely and re-assess every certificate issued under it. Upon taking this decision, Symantec committed to revalidating all 30,000+ certificates issued by their 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 and given Symantec's own investigations which discovered that CrossCert was not keeping adequate records of their issuance process. 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 Poliy or Certification Practice Statement". However, Symantec did not revoke all the certificates. | |||
When Symantec put various controls and restrictions in place following the previous "test cert" incident, those controls, checks and restrictions did not extend to their RA network. Symantec say that this is because the test tool used in the previous incident was not available to RAs; however, it does not seem to be a great leap to have looked for similar capabilities and problems elsewhere in their issuance process. | When Symantec put various controls and restrictions in place following the previous "test cert" incident, those controls, checks and restrictions did not extend to their RA network. Symantec say that this is because the test tool used in the previous incident was not available to RAs; however, it does not seem to be a great leap to have looked for similar capabilities and problems elsewhere in their issuance process. | ||
Symantec made a number of comments on this issue - [https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038 0], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933 1], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933 2], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825 3], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8843448 4]. | Symantec made a number of comments on this issue - [https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038 0], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933 1], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933 2], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825 3], [https://bug1334377.bmoattachments.org/attachment.cgi?id=8843448 4]. | ||
==Issue XXX: RA Program Audit Issues (2013 or earlier - March 2017)== | ==Issue XXX: RA Program Audit Issues (2013 or earlier - March 2017)== | ||
| Line 100: | Line 160: | ||
* the network was an insecure mess; and | * the network was an insecure mess; and | ||
* non-trusted staff had access to issuance. | * non-trusted staff had access to issuance. | ||
Ryan wrote: "have you examined the most recent set of audits? Do you, in your capacity | Ryan wrote: "have you examined the most recent set of audits? Do you, in your capacity | ||
| Line 108: | Line 166: | ||
not "WebTrust for CAs - SSL BR and Network Security". Do you believe that | not "WebTrust for CAs - SSL BR and Network Security". Do you believe that | ||
complies with letter of the Baseline Requirements?" | complies with letter of the Baseline Requirements?" | ||
===Symantec Response=== | |||
Symantec required the issues to be fixed and a 90-day action plan was executed to fix them. However, until they decided to shut down the RA program, no certificates issued during the period of suspect operations were checked to see if the poor practice had caused misissuance. | |||
Despite the clear warning signs shown on these audits, Symantec did not put in place any monitoring of their RAs, other than audit, to check that they were correctly performing the tasks delegated to them under the BRs. There were some - overridable - technical checks on certificate issuance. | Despite the clear warning signs shown on these audits, Symantec did not put in place any monitoring of their RAs, other than audit, to check that they were correctly performing the tasks delegated to them under the BRs. There were some - overridable - technical checks on certificate issuance. | ||
| Line 113: | Line 175: | ||
==Issue XXX: Incomplete RA Program Remediation (March 2017)== | ==Issue XXX: Incomplete RA Program Remediation (March 2017)== | ||
At the time Symantec shut down their RA program, they had four RAs - CrossCert, Certisign, Certsuperior, and Certisur. Symantec committed to revalidating all certificates issued by those RAs. However, the program previously had additional RAs, and Symantec has as yet taken no action to revalidate the certificates that they issued, despite some still being valid. Those RAs include at least E-Sign (from [https://cert.webtrust.org/SealFile?seal=1873&file=pdf at least March 1st 2014] to [https://cert.webtrust.org/SealFile?seal=1931&file=pdf at least July 31st 2015]). | At the time Symantec shut down their RA program, they had four RAs - CrossCert, Certisign, Certsuperior, and Certisur. Symantec committed to revalidating all certificates issued by those RAs. Independent of the rightness or otherwise of this course of action, it should have been applied consistently. However, the program previously had additional RAs, and Symantec has as yet taken no action to revalidate the certificates that they issued, despite some still being valid. Those RAs include at least E-Sign (from [https://cert.webtrust.org/SealFile?seal=1873&file=pdf at least March 1st 2014] to [https://cert.webtrust.org/SealFile?seal=1931&file=pdf at least July 31st 2015]) and may include others. | ||
===Symantec Response=== | |||
Symantec has not yet been officially requested to respond to this issue. | Symantec has not yet been officially requested to respond to this issue. | ||