Re: Symantec Test Cert Misissuance Incident
On Wed, Nov 25, 2015 at 12:15 PM, Kathleen Wilson wrote: > >> 4) As of June 1st, 2016, all certificates issued by Symantec itself will > be required to support Certificate Transparency and be published in CT. > Is this something Mozilla sees implemented as a technical measure within Firefox, or something Mozilla plans to measure or audit in other ways? -- Eric ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 11/25/15 9:15 AM, Kathleen Wilson wrote: On 10/28/15 2:30 PM, Kathleen Wilson wrote: On 10/28/15 2:14 PM, Kathleen Wilson wrote: Google has blogged about this: https://googleonlinesecurity.blogspot.com/2015/10/sustaining-digital-certificate-security.html All, We should discuss what actions Mozilla should require of Symantec, and what would be the penalty of not completing those actions. Thanks to all of you who have been providing thoughtful and constructive input into these discussions. I think we should create a Bugzilla bug with the following requirements: 1) Finish helping us update OneCRL with the appropriate records https://bugzilla.mozilla.org/show_bug.cgi?id=1214321#c20 2) Provide a set of steps Symantec will take (or has taken) to correct and prevent each of the identified failures, as well as a timeline for when they expect to complete such work. 3) The third-party security audit (may be part of the annual audits) must assess: - The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool. - That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key. - That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS. 4) As of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency and be published in CT. Other suggested action items I don't think we need to track: - They already updated their incident report. I doubt we'll get any more in that regard. - Their annual audit is probably happening about now or soon, so requiring a separate point-in-time assessment or another type of assessment is probably duplicate effort. - Notify all their cert holders about this incident -- I don't think that's actually a reasonable requirement, and I don't think it improves security, because there is no real action to suggest for the customers -- I don't think switching to a different CA guarantees better security. Thanks, Kathleen I filed the bug for tracking Symantec's action items regarding this incident: https://bugzilla.mozilla.org/show_bug.cgi?id=1229445 Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 10/28/15 2:30 PM, Kathleen Wilson wrote: On 10/28/15 2:14 PM, Kathleen Wilson wrote: Google has blogged about this: https://googleonlinesecurity.blogspot.com/2015/10/sustaining-digital-certificate-security.html All, We should discuss what actions Mozilla should require of Symantec, and what would be the penalty of not completing those actions. Thanks to all of you who have been providing thoughtful and constructive input into these discussions. I think we should create a Bugzilla bug with the following requirements: 1) Finish helping us update OneCRL with the appropriate records https://bugzilla.mozilla.org/show_bug.cgi?id=1214321#c20 2) Provide a set of steps Symantec will take (or has taken) to correct and prevent each of the identified failures, as well as a timeline for when they expect to complete such work. 3) The third-party security audit (may be part of the annual audits) must assess: - The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool. - That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key. - That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS. 4) As of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency and be published in CT. Other suggested action items I don't think we need to track: - They already updated their incident report. I doubt we'll get any more in that regard. - Their annual audit is probably happening about now or soon, so requiring a separate point-in-time assessment or another type of assessment is probably duplicate effort. - Notify all their cert holders about this incident -- I don't think that's actually a reasonable requirement, and I don't think it improves security, because there is no real action to suggest for the customers -- I don't think switching to a different CA guarantees better security. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
As the perennial bad guy, I look forward to Symantec (and others) publishing certs with CT. I can data-mine the logs to get a list of their customers and target them for any number of purposes. One possibility I'm considering: "Dear Symantec Customer: Did you hear about Symantec's recent trouble with certificate mis-issuance? We care deeply about your security, so please click on this link to verify that your own certificates have not been compromised" The linked site, of course, will infect the person's PC with malware. Or maybe it will be a site that tries to steal their business from Symantec. I haven't decided yet. Original Message From: Matt Palmer Sent: Thursday, October 29, 2015 3:49 PM On Thu, Oct 29, 2015 at 02:17:35PM +0100, Kurt Roeckx wrote: > On 2015-10-28 22:30, Kathleen Wilson wrote: > >According to the article, here is what Google is requiring of Symantec: > > > >1) as of June 1st, 2016, all certificates issued by Symantec itself will > >be required to support Certificate Transparency > > I know this is directly copied from their blog about this, but I wonder what > it means for a certificate to support CT. Is the requirement really that > all certificates need to published in CT? Yes, I'd say that's the intention. Further, I'll wager that Chromium will refuse to trust a certificate issued after the cutoff date which chains to a Symantec root, unless it is presented with sufficient SCTs to qualify under Chromium's CT policy. If Google's *really* playing hardball, they may require all existing Symantec certs to be enumerated for a whitelist, and will refuse to trust the notBefore date, similar to how existing EV certs were grandfathered. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 10/28/15 21:30, Kathleen Wilson wrote: > On 10/28/15 2:14 PM, Kathleen Wilson wrote: >> Google has blogged about this: >> >> https://googleonlinesecurity.blogspot.com/2015/10/sustaining-digital-certificate-security.html >> >> > > All, > > We should discuss what actions Mozilla should require of Symantec, and what > would be the penalty of not completing those actions. > > Of course, we still do not have the final report from Symantec, which may > change > things. > > According to the article, here is what Google is requiring of Symantec: > > 1) as of June 1st, 2016, all certificates issued by Symantec itself will be > required to support Certificate Transparency > > 2) further update their public incident report with: A post-mortem analysis > that > details why they did not detect the additional certificates that we found. > Details of each of the failures to uphold the relevant Baseline Requirements > and > EV Guidelines and what they believe the individual root cause was for each > failure. Based on the tone of Symantec's blog post, I fear such an assessment will have root causes like "employees failed to follow written domain validation procedures". Such a result would be unfortunate, because it would provide little insight into how the BRs and Mozilla's policies can be changed to prevent misissuance in the future. If the root cause is going to be "human error" of that sort, Mozilla should try to obtain an understanding of Symantec's procedures that should have prevented it (training, policy compliance monitoring, automation/UX provided by certificate issuance tools, availability of test CAs, etc.). [snip] > Do you all think we should simply require the same action items? > > Is there need to duplicate all of these requirements? > > Is there anything else we should require? On an different issue, I am curious whether any of the misissued certificates were reviewed as part of the quarterly self-audit of a 3% random sample of certificates required by the BRs. > > As always, I will appreciate your thoughtful and constructive input into this > discussion. > > Kathleen > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
From: Kathleen Wilson To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Symantec Test Cert Misissuance Incident On 10/28/15 2:14 PM, Kathleen Wilson wrote: Google has blogged about this: https://googleonlinesecurity.blogspot.com/2015/10/sustaining-digital-certificate-security.html We should discuss what actions Mozilla should require of Symantec, and what would be the penalty of not completing those actions. Do we know which exactly root certs were misused in this way? We will want to pull them from the list of certs SiteTruth trusts. John Nagle SiteTruth "Know who you're dealing with." ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
Extra requirement: * Symantec must notify each of it's EV and DV certificate holders once prominently at renewal time that "During the period of your last certificate, Symantec has failed to fully uphold it's duties to the Webtrust Requirements required by many browser vendors. You understand that the validity of the certificates you buy here could be terminated early if Symantec misses further requirements." Currently, customers are blissfully unaware of the potential benefits of one CA over another, or the potential cost to them if a CA has security issues, with most marketing based on who has the biggest golden padlock image on display. Text like this will help customers make an informed decision based on a CA's security history of technical success/failures. On Thursday, October 29, 2015 at 8:49:47 PM UTC, Matt Palmer wrote: > On Thu, Oct 29, 2015 at 02:17:35PM +0100, Kurt Roeckx wrote: > > On 2015-10-28 22:30, Kathleen Wilson wrote: > > >According to the article, here is what Google is requiring of Symantec: > > > > > >1) as of June 1st, 2016, all certificates issued by Symantec itself will > > >be required to support Certificate Transparency > > > > I know this is directly copied from their blog about this, but I wonder what > > it means for a certificate to support CT. Is the requirement really that > > all certificates need to published in CT? > > Yes, I'd say that's the intention. Further, I'll wager that Chromium will > refuse to trust a certificate issued after the cutoff date which chains to a > Symantec root, unless it is presented with sufficient SCTs to qualify under > Chromium's CT policy. If Google's *really* playing hardball, they may > require all existing Symantec certs to be enumerated for a whitelist, and > will refuse to trust the notBefore date, similar to how existing EV certs > were grandfathered. > > - Matt > > -- > Of course, I made the mistake of showing [a demo application] off to my boss, > who showed it off to his boss, and suddenly I couldn't reboot my desktop box > without getting a change control approved. > -- Derick Siddoway, in a place that doesn't exist ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On Thu, Oct 29, 2015 at 02:17:35PM +0100, Kurt Roeckx wrote: > On 2015-10-28 22:30, Kathleen Wilson wrote: > >According to the article, here is what Google is requiring of Symantec: > > > >1) as of June 1st, 2016, all certificates issued by Symantec itself will > >be required to support Certificate Transparency > > I know this is directly copied from their blog about this, but I wonder what > it means for a certificate to support CT. Is the requirement really that > all certificates need to published in CT? Yes, I'd say that's the intention. Further, I'll wager that Chromium will refuse to trust a certificate issued after the cutoff date which chains to a Symantec root, unless it is presented with sufficient SCTs to qualify under Chromium's CT policy. If Google's *really* playing hardball, they may require all existing Symantec certs to be enumerated for a whitelist, and will refuse to trust the notBefore date, similar to how existing EV certs were grandfathered. - Matt -- Of course, I made the mistake of showing [a demo application] off to my boss, who showed it off to his boss, and suddenly I couldn't reboot my desktop box without getting a change control approved. -- Derick Siddoway, in a place that doesn't exist ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
We have just posted an update to our test certificate incident report at https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_20151029.pdf. With regard to the questions on the certificates identified in this discussion, we have reviewed these and we see no anomalies with regard to logging: [3] https://crt.sh/?id=9314698 > pre-cert logged as part of our internal testing [4] https://crt.sh/?q=evgabrieltest%2Ebbtest%2Ecom&iCAID=1454 > cert logged as part of our internal testing [5] https://crt.sh/?id=5934504 > this was a properly issued certificate [6] https://crt.sh/?id=9324337 > pre-cert logged as part of internal testing [7] https://crt.sh/?id=10162388 > this was a properly issued certificate [8] https://crt.sh/?id=10162533 > this was a properly issued certificate [9] https://crt.sh/?id=10162537 > this was a properly issued certificate ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 29/10/15 13:17, Kurt Roeckx wrote: > I know this is directly copied from their blog about this, but I wonder > what it means for a certificate to support CT. Is the requirement > really that all certificates need to published in CT? That's a good question. I suspect they mean "be published in CT"; however, we could be more clear about what we mean when/if we publish our own requirements. > - Are all certificates really found now and revoked? As above, the > current state is unclear. Presumably when Symantec issue a final "final report" then that will be the sign that, to the best of their knowledge, they believe this to be true. > - Why are those test certificates signed by a real CA and not a test CA? Presumably because they want to test them in realistic scenarios with standard root stores. That's not to say that they shouldn't have done this in some cases. > It still conflicts with itself, it first says that there were 3 > certificate that shouldn't have been issued while the next paragraph > talks that there were 23. And then you have to go to the addendum to > see yet different numbers. I'm sure Rick will make sure that the final final report gets, at minimum, a copyediting pass :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 2015-10-28 22:30, Kathleen Wilson wrote: According to the article, here is what Google is requiring of Symantec: 1) as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency I know this is directly copied from their blog about this, but I wonder what it means for a certificate to support CT. Is the requirement really that all certificates need to published in CT? 2) further update their public incident report with: A post-mortem analysis that details why they did not detect the additional certificates that we found. Details of each of the failures to uphold the relevant Baseline Requirements and EV Guidelines and what they believe the individual root cause was for each failure. A few of the things that are currently unclear to me are: - Could any of those certificates have been abused, as in was it possible that the private key for any of those certificates was in the hands of a person. There were indications that this might be the case and I didn't see a reply about those. - Are all certificates really found now and revoked? As above, the current state is unclear. - It says that they have a tool that "a limited number of privileged QA personnel" can use and that this tool was misused (in this case). It also talks about an "authentication team" that can issue test certificates. Are this 2 different tools and does the "authentication team" use the normal (non-QA) tools to issue test certificates but then using a "specific review and approval process"? - What is the difference between the "specific review and approval process" and the normal process and why is this not the same? - How is personnel trained? - Why does the team training need to be changed if the tool does not allow issuing certificates for non-Symantec domains? - Why are those test certificates signed by a real CA and not a test CA? 5) The third-party security audit must assess: -- The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool. -- That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key. It would also be nice to know that a 3rd party couldn't control the private key. -- That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS. So this looks to be their current "final" report: https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3b.pdf It still conflicts with itself, it first says that there were 3 certificate that shouldn't have been issued while the next paragraph talks that there were 23. And then you have to go to the addendum to see yet different numbers. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 10/28/15 2:14 PM, Kathleen Wilson wrote: Google has blogged about this: https://googleonlinesecurity.blogspot.com/2015/10/sustaining-digital-certificate-security.html All, We should discuss what actions Mozilla should require of Symantec, and what would be the penalty of not completing those actions. Of course, we still do not have the final report from Symantec, which may change things. According to the article, here is what Google is requiring of Symantec: 1) as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency 2) further update their public incident report with: A post-mortem analysis that details why they did not detect the additional certificates that we found. Details of each of the failures to uphold the relevant Baseline Requirements and EV Guidelines and what they believe the individual root cause was for each failure. 3) provide ... a detailed set of steps they will take to correct and prevent each of the identified failures, as well as a timeline for when they expect to complete such work. Symantec may consider this latter information to be confidential and so we are not requesting that this be made public. 4) undergo a Point-in-time Readiness Assessment and a third-party security audit ... establish Symantec’s conformance to each of these standards: WebTrust CA, WebTrust BR, WebTrust EV 5) The third-party security audit must assess: -- The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool. -- That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key. -- That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS. Do you all think we should simply require the same action items? Is there need to duplicate all of these requirements? Is there anything else we should require? As always, I will appreciate your thoughtful and constructive input into this discussion. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
Google has blogged about this: https://googleonlinesecurity.blogspot.com/2015/10/sustaining-digital-certificate-security.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
We are working hard on providing an update and responding to open questions. We will provide further information as soon as its available. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
Rob, Gerv - Thanks for your input. We are collating all feedback and are planning to publish another update soon. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 15/10/15 10:54, Rob Stradling wrote: > Rick, your report [1] states that... > >"...the certificates never left Symantec's secure test labs or the A charitable reading of this might be "the private keys never left...". But yes, it might help to have more details on what exactly is being claimed here. > QA test machine, and they were never visible to any end user... > One of these test certificates with a CN=www.google.com was an > Extended Validation (EV) test certificate and was logged to public > Certificate Transparency (CT) log servers" > > IIUC, this statement claims that, out of all the certs/precerts listed > in [2], the www.google.com precertificate [3] is the only one that "left > Symantec's secure test labs". It would be helpful to know if the test certificate generation software logged the certs it generated to CT. If so, would we not expect more of them to be there? If not, how did some of them end up there? Were they placed there manually as part of the test? > - an EV cert for 123Symantec.com - see [6]. Note that that cert has a SAN for "san2.com", which is a domain owned by someone other than Symantec. > Also, when I looked for evidence of any of the other certs in [2] in > some of our historical SSL crawler logs, I was surprised to find that... These findings are indeed surprising, although it seems more likely that there are problems with Symantec's list than threats to the CA system. Previous Symantec test certs I've seen have had Symantec in the O field, which is not true for these. Rick: how are you determining which certs to add to your list? Are the ones Rob has found in the wild mistaken additions, or were they in fact test certs which were supposed not to leave the lab? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
Rick, your report [1] states that... "...the certificates never left Symantec's secure test labs or the QA test machine, and they were never visible to any end user... One of these test certificates with a CN=www.google.com was an Extended Validation (EV) test certificate and was logged to public Certificate Transparency (CT) log servers" IIUC, this statement claims that, out of all the certs/precerts listed in [2], the www.google.com precertificate [3] is the only one that "left Symantec's secure test labs". So, when I looked up all of the serial numbers in [2] in crt.sh, I was surprised to find... - 2 certs for *.icns.com.au (which you've explained already). - 2 precertificates, and the corresponding 2 EV certificates, for evgabrieltest.bbtest.com - see [4]. - an EV cert for symantec-waf01.scutum.jp - see [5]. - an EV cert for 123Symantec.com - see [6]. Also, when I looked for evidence of any of the other certs in [2] in some of our historical SSL crawler logs, I was surprised to find that... - the certificate with serial number 14c943, issued by "Equifax Secure Certificate Authority", was in use when we accessed https://avodcdn01-a.akamaihd.net on 9th June 2011 (IP address 184.86.230.82) and 25th June 2011 (IP address 95.101.190.82). This certificate wasn't known to CT until I logged it just now - see [7]. - the certificate with serial number 1962f4d772f9e9c7ef2d09dd40d85a2c, issued by "VeriSign Class 3 Extended Validation SSL SGC CA", was in use when we accessed https://remote.tdsolutionscenter.com (IP address 96.243.213.32) on the 8th, 11th, 13th and 22nd January 2013. remote.tdsolutionscenter.com still resolves to that IP address today. This certificate wasn't known to CT until I logged it just now - see [8]. I also found a copy of the certificate with serial number 64b32, issued by "GeoTrust DV SSL CA" (although for some reason I wasn't able to find a record of where we discovered that cert). This certificate wasn't known to CT until I logged it just now - see [9]. [1] https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3.pdf [2] https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf [3] https://crt.sh/?id=9314698 [4] https://crt.sh/?q=evgabrieltest%2Ebbtest%2Ecom&iCAID=1454 [5] https://crt.sh/?id=5934504 [6] https://crt.sh/?id=9324337 [7] https://crt.sh/?id=10162388 [8] https://crt.sh/?id=10162533 [9] https://crt.sh/?id=10162537 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 15/10/15 00:04, Rick Andrews wrote: On Tuesday, October 13, 2015 at 5:16:10 PM UTC-7, Charles Reiss wrote: This list of test certs for owned domains contains an entry for a cert with serial number 0xc222a issued by RapidSSL CA, valid from 05/18/2013 22:27:16 GMT to 06/20/2015 13:57:13 GMT (last entry of the owned domains PDF). This appears to be this certificate https://crt.sh/?id=1990400 which has: Thanks for your post. Symantec does not own the icns.com.au domain, but we had authorization by the domain owner to use the domain for testing. This icns.com.au test certificate was properly authenticated, and was installed and used externally by the domain owner. We included this certificate on our list of certificates associated with domains that we do not own, which is accurate. However, because we had authorization from the domain owner to issue the certificate, this certificate did not need to be on this list but was included for completeness. Hi Rick. Doesn't "installed and used externally" conflict with the following statement from your report [1] (emphasis mine) ? "Through a comprehensive internal review, we confirmed this incident was limited only to the issuance of test certificates, which *at all times were fully controlled within Symantec* and never posed any threat to any user or organization." BTW, [2] also lists another, older certificate for the same domain - *.icns.com.au: https://crt.sh/?id=658905 [1] https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3.pdf [2] https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 14/10/15 18:16, Gervase Markham wrote: On 14/10/15 13:47, Rob Stradling wrote: (There are actually 187 rows, but 3 certs are counted twice) And that's not perhaps because one copy is with a CT poison extension, and the other is with an SCT? That's extremely unlikely. None of those 3 are EV certs, none of them are in any of the known CT logs, and (looking at the Issue Dates) it looks like they were all issued before Symantec's CA systems had any support for CT. The 3 duplicate rows are: Serial Number: 27dc521a863f0921d023f5cda82b Issuer: Thawte DV SSL CA Issue Date: 02/13/2012 00:00:00 GMT Expiry Date: 02/12/2013 23:59:59 GMT Revoke Date: 10/09/15 Serial Number: 383b98e06ad18d776f2cd668200d9fef Issuer: GeoTrust SSL CA - G2 Issue Date: 03/21/2014 00:00:00 GMT Expiry Date: 03/21/2015 23:59:59 GMT Revoke Date: 04/10/14 Serial Number: 402ad03afe8c3341d452a5ac6efa1462 Issuer: GeoTrust SSL CA - G2 Issue Date: 03/21/2014 00:00:00 GMT Expiry Date: 03/21/2015 23:59:59 GMT Revoke Date: 04/10/14 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On Tuesday, October 13, 2015 at 5:16:10 PM UTC-7, Charles Reiss wrote: > On 10/13/15 18:46, Kathleen Wilson wrote: > > In September of this year, the CA Symantec revealed[0] that they had > > mis-issued > > a number of certificates for domains that they did not own or control, for > > testing purposes. After an "exhaustive review", they issued a Final > > Report[1] > > which documented 23 such certificates. > > > > Yesterday, Symantec updated their final report[2] to indicate that the > > problem > > was more extensive than they had at first believed. They said, in part: > > > > "While our current investigation is ongoing, so far we have found 164 > > additional > > instances where test certificates were inappropriately issued. All of these > > test > > certificates have been revoked. These test certificates were spread over 76 > > domain owners whom we are in the process of contacting." > > > > In addition, they have identified 3073 test certificates which were issued > > for > > domains which were (at the time) unregistered, since the practice was banned > > (which happened at different times for EV certs and other certs). They have > > provided two lists[3][4], one of the 164 certs and another of the 3073. > > This list of test certs for owned domains contains an entry for > a cert with serial number 0xc222a issued by RapidSSL CA, valid from 05/18/2013 > 22:27:16 GMT to 06/20/2015 13:57:13 GMT (last entry of the owned domains PDF). > This appears to be this certificate https://crt.sh/?id=1990400 which has: > > X509v3 Subject Alternative Name: > DNS:*.icns.com.au > DNS:icns.com.au > > As of this writing, there appears to be a functional server at that > www.icns.com.au which presents that (expired and revoked) cert and to which > openssl s_client can successfully connect. > > Is this entry an error? > > In Symantec's initial incident report, they indicated 'the private keys > associated with the test certificates were all destroyed as part of the > testing > tool that was used to enroll for the test certificates'. Are they still making > this claim for the test certificates found subsequently? > > - Charles > > > > > > They are continuing to search, and will update the Final Report again when > > their > > investigations are complete. > > > > The 164 certificates will be added to Mozilla's OneCRL system[5]. (We do not > > think the risk from the 3073 is significant enough to warrant this step.) > > > > This message has been posted to begin a discussion in the Mozilla community > > as > > to what additional action, if any, Mozilla should take in response to these > > events. > > > > Kathleen, Gerv and Richard > > > > [0]http://www.symantec.com/connect/blogs/tough-day-leaders > > [1]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report.pdf > > > > [2]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_12_2015.pdf > > > > [3]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf > > > > [4]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregistered.pdf > > > > [5]https://bugzilla.mozilla.org/show_bug.cgi?id=1214321 Thanks for your post. Symantec does not own the icns.com.au domain, but we had authorization by the domain owner to use the domain for testing. This icns.com.au test certificate was properly authenticated, and was installed and used externally by the domain owner. We included this certificate on our list of certificates associated with domains that we do not own, which is accurate. However, because we had authorization from the domain owner to issue the certificate, this certificate did not need to be on this list but was included for completeness. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 14/10/15 13:47, Rob Stradling wrote: > (There are actually 187 rows, but 3 certs are counted twice) And that's not perhaps because one copy is with a CT poison extension, and the other is with an SCT? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 13/10/15 19:46, Kathleen Wilson wrote: They have provided two lists[3][4], one of the 164 certs and another of the 3073. [3]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf [4]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregistered.pdf I count 184 certs in [3], not 164. (There are actually 187 rows, but 3 certs are counted twice) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 14/10/15 01:15, Charles Reiss wrote: > As of this writing, there appears to be a functional server at that > www.icns.com.au which presents that (expired and revoked) cert and to which > openssl s_client can successfully connect. > > Is this entry an error? Thank you for doing this investigation. That's a good question; this cert does not look like the other test certs. I will ask Symantec. > In Symantec's initial incident report, they indicated 'the private keys > associated with the test certificates were all destroyed as part of the > testing > tool that was used to enroll for the test certificates'. Are they still making > this claim for the test certificates found subsequently? Another good question I will pass on :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 13/10/15 23:58, Michael Colburn wrote: > Symantec's gone and updated [2] and [4] and both of those links are > 404ing now. Updated links: > > [2] > https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3.pdf > [4] > https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregisteredv2.pdf The change seems to be to revise the figure for test certs for unregistered domains down from 3073 to 2548. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
On 10/13/15 18:46, Kathleen Wilson wrote: > In September of this year, the CA Symantec revealed[0] that they had > mis-issued > a number of certificates for domains that they did not own or control, for > testing purposes. After an “exhaustive review”, they issued a Final Report[1] > which documented 23 such certificates. > > Yesterday, Symantec updated their final report[2] to indicate that the problem > was more extensive than they had at first believed. They said, in part: > > “While our current investigation is ongoing, so far we have found 164 > additional > instances where test certificates were inappropriately issued. All of these > test > certificates have been revoked. These test certificates were spread over 76 > domain owners whom we are in the process of contacting.” > > In addition, they have identified 3073 test certificates which were issued for > domains which were (at the time) unregistered, since the practice was banned > (which happened at different times for EV certs and other certs). They have > provided two lists[3][4], one of the 164 certs and another of the 3073. This list of test certs for owned domains contains an entry for a cert with serial number 0xc222a issued by RapidSSL CA, valid from 05/18/2013 22:27:16 GMT to 06/20/2015 13:57:13 GMT (last entry of the owned domains PDF). This appears to be this certificate https://crt.sh/?id=1990400 which has: X509v3 Subject Alternative Name: DNS:*.icns.com.au DNS:icns.com.au As of this writing, there appears to be a functional server at that www.icns.com.au which presents that (expired and revoked) cert and to which openssl s_client can successfully connect. Is this entry an error? In Symantec's initial incident report, they indicated 'the private keys associated with the test certificates were all destroyed as part of the testing tool that was used to enroll for the test certificates'. Are they still making this claim for the test certificates found subsequently? - Charles > > They are continuing to search, and will update the Final Report again when > their > investigations are complete. > > The 164 certificates will be added to Mozilla’s OneCRL system[5]. (We do not > think the risk from the 3073 is significant enough to warrant this step.) > > This message has been posted to begin a discussion in the Mozilla community as > to what additional action, if any, Mozilla should take in response to these > events. > > Kathleen, Gerv and Richard > > [0]http://www.symantec.com/connect/blogs/tough-day-leaders > [1]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report.pdf > > [2]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_12_2015.pdf > > [3]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf > > [4]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregistered.pdf > > [5]https://bugzilla.mozilla.org/show_bug.cgi?id=1214321 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Test Cert Misissuance Incident
Symantec's gone and updated [2] and [4] and both of those links are 404ing now. Updated links: [2] https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3.pdf [4] https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregisteredv2.pdf Michael On 13 October 2015 at 14:46, Kathleen Wilson wrote: > In September of this year, the CA Symantec revealed[0] that they had > mis-issued a number of certificates for domains that they did not own or > control, for testing purposes. After an “exhaustive review”, they issued a > Final Report[1] which documented 23 such certificates. > > Yesterday, Symantec updated their final report[2] to indicate that the > problem was more extensive than they had at first believed. They said, in > part: > > “While our current investigation is ongoing, so far we have found 164 > additional instances where test certificates were inappropriately issued. > All of these test certificates have been revoked. These test certificates > were spread over 76 domain owners whom we are in the process of contacting.” > > In addition, they have identified 3073 test certificates which were issued > for domains which were (at the time) unregistered, since the practice was > banned (which happened at different times for EV certs and other certs). > They have provided two lists[3][4], one of the 164 certs and another of the > 3073. > > They are continuing to search, and will update the Final Report again when > their investigations are complete. > > The 164 certificates will be added to Mozilla’s OneCRL system[5]. (We do not > think the risk from the 3073 is significant enough to warrant this step.) > > This message has been posted to begin a discussion in the Mozilla community > as to what additional action, if any, Mozilla should take in response to > these events. > > Kathleen, Gerv and Richard > > [0]http://www.symantec.com/connect/blogs/tough-day-leaders > [1]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report.pdf > [2]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_12_2015.pdf > [3]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf > [4]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregistered.pdf > [5]https://bugzilla.mozilla.org/show_bug.cgi?id=1214321 > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Symantec Test Cert Misissuance Incident
In September of this year, the CA Symantec revealed[0] that they had mis-issued a number of certificates for domains that they did not own or control, for testing purposes. After an “exhaustive review”, they issued a Final Report[1] which documented 23 such certificates. Yesterday, Symantec updated their final report[2] to indicate that the problem was more extensive than they had at first believed. They said, in part: “While our current investigation is ongoing, so far we have found 164 additional instances where test certificates were inappropriately issued. All of these test certificates have been revoked. These test certificates were spread over 76 domain owners whom we are in the process of contacting.” In addition, they have identified 3073 test certificates which were issued for domains which were (at the time) unregistered, since the practice was banned (which happened at different times for EV certs and other certs). They have provided two lists[3][4], one of the 164 certs and another of the 3073. They are continuing to search, and will update the Final Report again when their investigations are complete. The 164 certificates will be added to Mozilla’s OneCRL system[5]. (We do not think the risk from the 3073 is significant enough to warrant this step.) This message has been posted to begin a discussion in the Mozilla community as to what additional action, if any, Mozilla should take in response to these events. Kathleen, Gerv and Richard [0]http://www.symantec.com/connect/blogs/tough-day-leaders [1]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report.pdf [2]https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_12_2015.pdf [3]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf [4]https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportUnregistered.pdf [5]https://bugzilla.mozilla.org/show_bug.cgi?id=1214321 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
