Changes

Jump to: navigation, search

CA/Symantec Issues

5,420 bytes added, 15:46, 29 March 2017
Further info; still draft
The issues are in broadly chronological order.
 
==Issue XXX: Insecure Issuance API (2013 - November 2016)==
 
According to [https://www.facebook.com/cbyrneiv/posts/10155129935452436 reports] and the press, 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 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]:
 
<blockquote>
"We have looked into Chris Byrne’s research claim and could not recreate the problem. We would welcome the proof of concept from the original research in 2015 as well as the most recent research. In addition, we are unaware of any real-world scenario of harm or evidence of the problem. However, we can confirm that no private keys were accessed, as that is not technically feasible.
</blockquote>
==Issue XXX: Issued Certificate Directly From Root (Dec 2013 - Jan 2014)==
==Issue XXX: Accidental 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. They Therefore they had to revoke all of the 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: RA Program Misissuances ()== 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 policy. However, In January 2017, [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ it was discovered] that a number of test certificates had been issued by Symantec intermediates. The investigation of these matters led to increasing further discoveries of misissuances and potential misissuances, together with poor CA practice, by companies in Symantec's RA network. Due to these discoveries, Symantec subsequently decided to shut down the program entirely and revalidate every certificate issued under it. This issue deals with the certificate misissuances; the following issue deals with the audit-related problems uncovered. ==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 - 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. Over multiple years ([https://www.symantec.com/content/en/us/about/media/repository/symantec-webtrust-audit-report.pdf 2013-12-01 to 2014-11-30], [https://www.symantec.com/content/en/us/about/media/repository/GeoTrust-WTBR-2015.pdf 2014-12-01 to 2015-11-30]), Symantec's "GeoTrust" audits were qualified to say that they did not have proper audit information for some of these RAs. This information was in their management assertions, and repeated in the audit findings. So the poor audit situation was ongoing and known. Also, other audit reports, despite being in hierarchies accessible for issuance by the same RAs, did not have similar qualifications ([https://www.symantec.com/content/en/us/about/media/repository/Symantec-STN-WTCA-2015.pdf Symantec Trust Network, 2014-12-01 to 2015-11-30]).  One Symantec RA, Certsuperior, had a [https://bug1334377.bmoattachments.org/attachment.cgi?id=8831930 particularly dreadful audit]:  * There was no legible CPS;* inadequately-trained personnel were doing issuance;* 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 capacityas CA Certificate policy peer, believe the audits were correct for theircapability and role? Note that several of them were "WebTrust for CAs" -not "WebTrust for CAs - SSL BR and Network Security". Do you believe thatcomplies with letter of the Baseline Requirements?" 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.
Accountapprovers, antispam, confirm, emeritus
4,925
edits

Navigation menu