Changes

Jump to: navigation, search

CA/Symantec Issues

2,071 bytes added, 17:37, 29 March 2017
Further updates
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].
The issues are in broadly chronological orderby end date.
==Issue XXX: Insecure Issuance API Certificate Issued Directly From Root (Dec 2013 - November 2016Jan 2014)==
According Symantec issued a cert to [https://www.facebook.com/cbyrneiv/posts/10155129935452436 a report]one of its customers, for several years Symantec operated an issuance API which was insufficiently securePitney Bowes, such that URL parameter substitution attacks would allow did not comply with at least one customer to view, reissue, revoke and otherwise control certificates (including non-server certs) belonging to another customer. When made aware provision of these issuesthe CA/Browser Forum Baseline Requirements, Symantec took in that it was issued directly from a very long time to fix them, and they may not have been fully fixed at the time Symantec terminated its RA program entirelyroot.
Symantec has This cert was a 1024-bit cert, but if it was issued in 2013, that was neither a BR nor a Mozilla policy violation, as the 1024-bit issuance deadline was 31st December 2013. It was also backdated, but that is not yet been formally asked by a BR or Mozilla policy violation either, as long as it was not done to respond 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 this issuetell 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. However, they commented [http://www6).csoonline20 bits of entropy is a MUST in the Mozilla policy (2.com/article/3184897/security/api-flaws-said-2), but it doesn't say it has tobe in the serial number -have-left-symantec-ssl-certificates-vulnerable-to-compromiseit could be that they randomised the notBefore time.html to I am told Microsoft removed the allowance for doing entropy in the press]:Date field on 11th November 2013, so this was a violation of their policies XXXURL.
<blockquote>"We have looked into Chris Byrne’s research claim and could not recreate Symantec believed this was the problem. We would welcome the proof only technical way to ensure continuity of concept from service for the original research customer concerned. However, they did not request permission to issue in 2015 as well as advance, disclosed the most recent research. In additionissuance a month after it had happened, we are unaware of any real-world scenario of harm or evidence of and the replacement certificate (unlike the problem. However, we can confirm that no private keys were accessed, as that is not technically feasibleoriginal) asserted a "BR Compliant" OID. </blockquote>
==Issue XXX: Issued Certificate Directly From Root (Dec 2013 - Jan Symantec disclosed this issuance to Mozilla at the end of January 2014)==. 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. ==Issue XXX: Test Certificate Misissuance (April 2009 - September 2015)==
This cert was a 1024-bit certBetween 2009 and 2015, but if it was Symantec issued a large number of test certificates in 2013, that was neither a BR nor a Mozilla policy violation, as the 1024-bit issuance deadline was 31st December 2013their publicly trusted hierarchies. It was also backdated, but These contained domains that is Symantec did not a BR own or Mozilla policy violation eithercontrol, as long as it and for which domain validation was not done to evade a technical controlperformed. If it was in fact issued in early 2014, it would be a violation of all Some of these requirementsdomains were unregistered, but there is no way for us and others were owned by other organizations. The registered domains used included those belonging to tell Google, Opera and so we must take other organizations. Some of the test certificates left Symantec's word for it. It also has a short serial number, but entropy network because they were logged 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 (2CT; Symantec claims no others did.2)However, but it doesn't say it has Symantec personnel would have had access to be in the serial number - it could be that they randomised public and private keys of the notBefore timecerts.
It took quite a while for the full scale of the problem to emerge, and Symantec believed this was the only technical way had to publish numerous updates to ensure continuity their "Final Report". Symantec released a number of service for the customer concerneddocuments 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. Howeverpdf list of certs containing owned domains], they did not request permission to issue in advance[https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregisteredv2.pdf list of certs containing unregistered domains], disclosed the issuance a month after it had happened[https://www.symantec.com/page.jsp?id=test-certs-update further update]. Their blog post, and the replacement certificate (unlike the original) asserted a "BR Compliant[http://www.symantec.com/connect/blogs/tough-day-leaders A Tough Day As Leaders]" OIDappears to no longer be online.
Symantec disclosed Some details of this issuance to Mozilla at the end of January 2014. The incident is are recorded in {{bug|9663501214321}}.
==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. They were not the only CA to have similar issues with accidental SHA-1 issuance.
==Issue XXX: SHA-1 Issuance After Deadline - 2 , 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. (Mozilla considers that it is.) Their explanation for the incident was as follows:
It is concerning that their first experience with SHA-1 misissuance did not cause them to analyse their systems and find this potential problem.
 
==Issue XXX: Cross-Signing the US Federal Bridge (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.
 
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. 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 [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/VjRDU_VAOf8/r8xhGtUWAgAJ accidentally] issued real certificates - i.e. they signed the tbsCertificate data using SHA-1. Therefore they had 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)==
This incident is recorded in {{bug|1261919}}.
==Issue XXX: CrossInsecure Issuance API (2013 or earlier -Signing the US Federal Bridge (July November 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.
Symantec According to [https://groupswww.googlefacebook.com/forumcbyrneiv/#!msgposts/mozilla.dev.security.policy/0wSUJKnH5MY/PGhVbV-UBQAJ cross-signed10155129935452436 a report] , for several years Symantec operated an issuance API which was insufficiently secure, such that URL parameter substitution attacks would allow one of the root CAs in the FPKIcustomer to view, reissue, thereby making revoke and otherwise control certificates below that root in the chain of trust be publicly trusted. This intermediate CA was not disclosed in the CCADB(including non-server certs) belonging to another customer. When this was drawn made aware of these issues, Symantec took a very long time to their attentionfix them, Symantec [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/OAJD-tWBAAAJ did and they may not revoke] have been fully fixed at the cross-sign, instead allowing it to expire (less than a month later)time Symantec terminated its RA program entirely.
==Issue XXXSymantec has not yet been formally asked by Mozilla to respond to this issue. However, they commented [http: Accidental Manual Signing Using SHA//www.csoonline.com/article/3184897/security/api-1 (July 2016)==flaws-said-to-have-left-symantec-ssl-certificates-vulnerable-to-compromise.html to the press]:
Symantec applied to <blockquote>"We have looked into Chris Byrne’s research claim and could not recreate the root programs for leave to issue SHA-1 certificates for a customerproblem. As part We would welcome the proof of that process, they planned to prepare tbsCertificates ("To Be Signed Certificates" - all concept from the data except for original research in 2015 as well as the signature) for CAB Forum reviewmost recent research. HoweverIn addition, they [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/VjRDU_VAOf8/r8xhGtUWAgAJ accidentally] issued we are unaware of any real certificates - i.e. they signed world scenario of harm or evidence of the tbsCertificate data using SHA-1problem. Therefore they had to revoke all of those certificatesHowever, and issue new ones after permission was granted. This was supposedly a manual process but it seems like the relevant instructions we can confirm that no private keys were either deficient or accessed, as that is not followedtechnically feasible.</blockquote>
==Issue XXX: 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.
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: 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]). Symantec has not yet been officially requested to respond to this issue. ==Issue XXX: RA Program Audit Issues (XXX 2013 or earlier - March 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.
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. 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]).
 
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/1167038"

Navigation menu