Changes

Jump to: navigation, search

CA/Symantec Issues

1,934 bytes added, 12:04, 30 March 2017
Add letters
The issues are in broadly chronological order by end date.
==Issue XXXB: 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 both the CA/Browser Forum Baseline Requirementsand Mozilla policy. Firstly, in that it was issued directly from a root, and that secondly 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 ([https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_6.pdf version 1.1.6]). 20 bits of entropy is a MUST in the Mozilla policy ([https://github.com/mozilla/pkipolicy/blob/2.2/rootstore/policy.md version 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.  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.
The incident is recorded in {{bug|966350}}.
===Symantec Response===
Symantec self-reported this issuance to Mozilla [https://bugzilla.mozilla.org/show_bug.cgi?id=966350 via Bugzilla] at the end of January 2014. Even though a [https://bugzilla.mozilla.org/show_bug.cgi?id=966350#c2 question was asked] about the BR Compliance OID that the new cert asserted, they did not comment on the bug beyond the initial report.
===Further Comments and Conclusion===
Symantec did not request permission to issue The lack of discussion in advance, they disclosed the issuance at least a month after it had happened, delayed disclosure and the replacement certificate (unlike the original) asserted inclusion of a "BR Compliant" -compliant OIDin a certificate Symantec knew was not BR-compliant are all disappointing.
==Issue XXXD: 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 Software. Given the numbers involved, this sort of test certificate issuance appears to have been common practice at Symantec. Some of the test certificates (including one for www.google.com) 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-securebugzilla.symantecmozilla.com/connect/sites/default/filesorg/Test_Certificates_Incident_Final_Reportattachment.pdf cgi?id=8852861 Final Report], [https://www-securebugzilla.symantecmozilla.com/connectorg/sites/default/files/Test_Certificates_Incident_Final_Report_10_12_2015attachment.pdf cgi?id=8852862 Final Report v2], [https://www-securebugzilla.symantecmozilla.com/connect/sitesorg/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3attachment.pdf cgi?id=8852863 Final Report v3], [https://www-securebugzilla.symantecmozilla.com/connect/sites/defaultorg/files/TestCertificateIncidentReportOwnedDomainsattachment.pdf cgi?id=8852864 list of certs containing owned domains], [https[Media://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. In their report, Symantec wrote: <blockquote>We have identified three root causes underlying the mis-issuance of these test certificates. First, we continued to issue internal test certificates to unregistered domains after the April 2014 change in the Baseline Requirements that removed authorization to do so. The overwhelming majority of the mis-issued test certificates fall into this first category. Second, certain Symantec Quality Assurance (QA) personnel had systems access, including the ability to use certain legacy tools, which enabled them to request a limited number of test certificates that were issued without review by authentication personnel. Third, authentication personnel did not consistently follow all verification steps when they received test certificate requests from their Symantec colleagues, or requested test certificates themselves. </blockquote>
Symantec took a number of remediation steps, as outlined in the report. ==Issue XXXF: Audit Issues For Symantec Itself (December 2014 - November 2015)==
All of Symantec's current audit reports can be found in their [https://www.symantec.com/about/legal/repository.jsp legal repository]. I don't believe they provide links to historic versions. Symantec's standard audit period is from December 1st to November 31st. We would therefore expect their 2016 audit to be available by now. However Symantec regularly only supplies their audit reports more than 180 days after the audit has been completed. The Baseline Requirements section 8.6 says that CAs SHOULD provide them in 90 days or fewer. Symantec is not the only CA which regularly supplies its audits late.
Each of the documents contains, in a following table, Symantec's comments on the qualifications and what they have done or are doing to remedy them.
===Further Comments and Conclusion=== Mozilla did not object to these qualifications in Symantec's audits at the time the audit documentation was submitted to us. Because of this, it is not reasonable for us to take action based on the mere existence of these qualifications. They are listed here because they are one part of the general picture of Symantec's compliance or otherwise with the BRs. An audit with any qualifications at all is not particularly common among CAs; six qualification is a lot.
==Issue XXXH: 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. Therefore, they passed through the point in the process where the presence of SHA-1 was checked for before the check was enabled.
===Symantec Response===
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 XXXJ: 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 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.)
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 XXXL: 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.
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 XXXN: 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 [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 XXXP: 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.
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 XXXR: 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.
</blockquote>
==Issue XXXT: RA Program Misissuances (January 2010 - January 2017)==
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.
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.
==Issue XXXV: RA Program Audit Issues (2013 or earlier - January 2017)==
Symantec's RAs appear to have had a history of poor compliance with the BRs and other audit requirements, facts which were known to Symantec but not disclosed to Mozilla or dealt with in appropriately comprehensive ways.
[https://cert.webtrust.org/SealFile?seal=2168&file=pdf CrossCert's audit] does not list or cover the full number of Symantec roots under which they had issuance capability. Symantec's investigation discovered that CrossCert had the scope of the audit reduced for cost reasons.
[https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929 Certisign's audit] and [https://cert.webtrust.org/SealFile?seal=2067&file=pdf Certisur's audit] are only WebTrust for CAs audits - neither CA appears to have a Baseline Requirements audit. Mozilla policy requires "CA operations and issuance of certificates to be used for SSL-enabled servers" to conform to the Baseline Requirements. As Symantec has stated that audit was their only mechanism for monitoring their RAs, which is required for entities doing independent certificate issuance as they can have had no assurance that RAs without a BR audit wereactually following the BRs.
===Symantec Response===
Despite the clear warning signs shown on the Certsuperior audit, 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.
Symantec appears to have taken no action to deal with that fact that Certisign and Certisur did not have the correct BR audits.
Symantec did not notice that CrossCert's audits did not cover all the relevant roots until they did the RA investigation in early 2017.
==Issue XXXX: Incomplete RA Program Remediation (February - 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.
Accountapprovers, antispam, confirm, emeritus
4,925
edits

Navigation menu