Changes

Jump to: navigation, search

CA/Symantec Issues

3,426 bytes added, 21:08, 29 March 2017
Further expansion
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.
==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 issued a cert to one of its customers, Pitney Bowes, that did not comply with at least one provision of the CA/Browser Forum Baseline Requirements, in that it was issued directly from a root. Response===
This cert was a 1024Symantec self-bit cert, but if it was issued in 2013, that was neither a BR nor a Mozilla policy violation, as the 1024-bit reported this issuance deadline was 31st December 2013. It was also backdated, but that is not a BR or Mozilla policy violation either, as long as it was not done to evade a technical control. If it was in fact issued in early 2014, it would be a violation of all of these requirements, but there is no way for us to tell and so we must take Symantec's word for it. 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 at the Date field on 11th November 2013, so this was a violation end of their policies XXXURLJanuary 2014.
Symantec believed this was the only technical way to ensure continuity of service for the customer concerned. However, they did not request permission to issue in advance, disclosed the issuance a month after it had happened, ===Further Comments and the replacement certificate (unlike the original) asserted a "BR Compliant" OID.Conclusion===
Symantec did not request permission to issue in advance, they disclosed this the issuance to Mozilla at least a month after it had happened, and the end of January 2014. The incident is recorded in {{bug|966350}}replacement certificate (unlike the original) asserted a "BR Compliant" OID.
==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, and Opera and other organizationsSoftware. 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.
It took quite a while for the full scale Some details 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]. Their blog post, "[http://www.symantec.com/connect/blogs/tough-day-leaders A Tough Day As Leaders]" appears to no longer be onlineincident are recorded in {{bug|1214321}}.
Some details ===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 incident are recorded in {{bug|1214321}}- [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)==
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. They  ===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)==
Symantec issued a [https://crt.sh/?id=13407116&opt=cablint SHA-1 CT precertificate] in February 2016. They then seemed to claim, contrary to the CT RFC, 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 it pre-certificate misissuance ismisissuance.)  ===Symantec Response=== Their explanation for the incident was as follows:
<blockquote>
</blockquote>
===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)==
==Issue XXX: Cross-Signing The US Government has an extremely complicated PKI called the US Federal Bridge (July 2016)=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.
The US Government has an extremely complicated PKI called the Federal PKI. It has Presumably in November or December of 2015, Symantec [https://bugzillagroups.google.com/forum/#!msg/mozilla.orgdev.security.policy/0wSUJKnH5MY/show_bug.cgi?id=478418 applied for inclusionPGhVbV-UBQAJ cross-signed] one of the root CAs in the Mozilla FPKI ("Federal Bridge CA 2013"), thereby making certificates below that root store but that application seemed unlikely ever to in the chain of trust be successful due publicly trusted, and technically making Symantec responsible to Mozilla for all certificates issued in the difficulty covered part of bringing the entire FPKI , including any BR violations. The [https://crt.sh/?id=12638543 intermediate CA certificate concerned] was not disclosed in line with the CCADB, as Mozilla's policiespractice at the time required.
===Symantec [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/PGhVbV-UBQAJ cross-signed] one of the root CAs in the FPKI, thereby making certificates below that root in the chain of trust be publicly trusted. This intermediate CA was not disclosed in the CCADB. 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)==
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 accidentallyself-reported] issued real certificates - ithis issue to Mozilla.e. they signed the tbsCertificate data using SHA-1. Therefore they had Their remediation was to revoke all of those certificates, and issue new ones after permission was granted. This was supposedly a manual process but it seems like the relevant instructions were either deficient or not followed.
==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.
 
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.
 
This incident is recorded in {{bug|1261919}}.
==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.
 
===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]:
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. Due to these discoveries, Symantec subsequently decided to shut down the RA program entirely and re-assess every certificate issued under it. This issue deals with the certificate misissuances; the following issue deals with the audit-related problems uncovered.
Types of misissuance by CrossCert:
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.
Upon deciding This incident is recorded in {{bug|1334377}}. ===Symantec Response=== Due to these discoveries, Symantec subsequently decided to close shut down the RA programentirely 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.
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].
 
This incident is recorded in {{bug|1334377}}.
==Issue XXX: RA Program Audit Issues (2013 or earlier - March 2017)==
* the network was an insecure mess; and
* non-trusted staff had access to issuance.
 
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.
Ryan wrote: "have you examined the most recent set of audits? Do you, in your capacity
not "WebTrust for CAs - SSL BR and Network Security". Do you believe that
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.
==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. 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.
Gerv
Accountapprovers, antispam, confirm, emeritus
4,925
edits
Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1167050"

Navigation menu