Re: How do you handle mass revocation requests?
Is Trustico's storage of private keys related to this security report from a few months back (which did not appear to ever have been fully investigated...)? https://groups.google.com/d/msg/mozilla.dev.security.policy/CEww8w9q2zE/F_bzX1guCQAJ Does Digicert have (or will it have) some sort of process in place to prevent resellers from storing private keys so casually? On Wednesday, February 28, 2018 at 12:38:16 PM UTC-5, Jeremy Rowley wrote: > Hi everyone, > > > > I wanted to share an incident report regarding the revocation of certain > certificates ordered through a reseller. > > > > On February 2nd, 2018, we received a request from Trustico to mass revoke > all certificates that had been ordered by end users through Trustico. > Unfortunately, the email was not sent to the appropriate certificate problem > reporting channels and did not surface immediately so we're delayed in > sharing the concerns and information. Once we were alerted, the team kicked > off a debate that I wanted to bring to the CAB Forum. Basically, our > position is that resellers do not constitute subscribers under the Baseline > Requirement's definitions (Section 1.6.1). As such, we needed to confirm > that either the key was compromised or that they revocation was authorized > by the domain holder (the subscriber) prior to revoking the certificate. The > certificates were not alleged as compromised at that time. > > > > Later, the company shared with us that they held the private keys and the > certificates were compromised, trying to trigger the BR's 24-hour revocation > requirement. However, we insisted that the subscriber must confirm the > revocation request or there must be evidence of the private key compromise. > > > > Normally, we permit partners to revoke and manage the certificates freely on > behalf of their customer, with DigiCert providing all validation and > issuance services. However, the sheer number of revocation requests (50k) > and allegation of compromise triggered concerns around the impact to the web > and browser users. Therefore, this was categorized as high risk, especially > considering the relationship between Trustico and DigiCert is terminating. > > > > On 2/27/2018, at my request for proof of compromise, we received a file with > 23k private keys matched to specific Trustico customers. This definitely > triggered our 24-hour revocation processing requirement under 4.9.1.1.3. > Once we received the keys, we confirmed that these were indeed the matching > private keys for the reported certificates. We will be revoking these > certificates today (February 28th, 2018). > > > > At this time, Trustico has not provided any information about how these > certificates were compromised or how they acquired the private keys. As is > standard practice for a Certificate Authority, DigiCert never had possession > of these private keys. > > > > Currently, we are only revoking the certificates if we received the private > keys. There are additional certificates the reseller requested to have > revoked, but DigiCert has decided to disregard that request until we receive > proof of compromise or more information about the cause of this incident. > > > > DigiCert sent out emails to the affected customers in order to notify them > that their certificate(s) are being revoked. This revocation only affects > those customers and there is no additional exposure that we are aware of at > this time, nor any reason to believe there is. > > > > This raises a question about the MDSP policy and CAB Forum requirements. Who > is the subscriber in the reseller relation? We believe this to be the key > holder. However, the language is unclear. I think we followed the letter and > spirit of the BRs here, but I'd like feedback, perhaps leading to a ballot > that clarifies the subscriber in a reseller relationship. > > > > This also brings up a ballot about the level of due diligence required for > cert revocation. We generally believe that the private key or demonstration > of domain control is sufficient to request revocation. Others are at the CAs > discretion. Should we clarify what the due diligence looks like? Are there > other things we should have done or been doing? > > > > What kind of transparency would the Mozilla community like around this > issue? There aren't many more facts than I shared above, but there is a lot > of speculation. Let me know what I can share to help alleviate confusion and > answer questions. > > > > Jeremy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PROCERT issues
Why does the document say "Date: 11/07/17" on every page, and the signed pdf metadata say 2017-09-25T17:14:35-04:00 2017-09-25T17:18:07-04:00 2017-09-25T17:18:07-04:00 On Tuesday, September 26, 2017 at 4:56:36 PM UTC-4, alejand...@gmail.com wrote: > In the following link you can find the CPS in English language > > https://www.procert.net.ve/documentos/CPS-PROCERT.pdf ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom cross-signs disclosed by Certinomis
Can this be responded to more directly and comprehensively please? Are there any staff or personnel being shared between WoSign and Startcom? This includes any staff from (or paid by) Qihoo 360 its subsidiaries, contractors, or affiliates--does anyone do any work (paid or unpaid) for both Wosign and Startcom? Are there any personnel switching between WoSign and Startcom? On Tuesday, August 8, 2017 at 4:39:39 AM UTC-4, Inigo Barreira wrote: > Hi, > > 1.- yes, I said many times that it was not a good decission and of course not > the best way to start, but at all times these test certs were under control, > lived only for some minutes. Everything was explained in bugzilla #1369359 > > 2.- Those pre-certificates were related to these test certificates for the CT > testing, and yes, technically they didn´t exist for EJBCA, so we were dealing > with them on how to revoke them without issuing them wrongly and finally got > a solution, and then inmediately revoked them. > > So, these two issues were related to the same generic problem, the CT > testing, which was only for Chrome compliance, but that were all the time > controlled by us. It was a bad practice that it´s not happening again with > the countermeasures set as explained. > > 3.- No, there´s nothing related to Wosign nor Richard Wang. As indicated in > our remediation plan, 360 owns 100% of StartCom and we´ve performed all the > changes proposed there to have nothing related to Wosign nor Richard. This is > indicated in bugzilla #1311832 and also in the remediation plan delivered > last year. > Also in our remediation plan, there was a chart in which was indicated how > the Company is structured, and in the case of StartCom Spain, this is 100% > owned by the StartCom UK, and I´m director in both offices. > > And the reason why Richard Wang is director again in StartCom UK is due to > some bank issues. Richard was removed as director of the StartCom UK at that > time, but didn´t realize about his signatory rights in the UK bank account. > We thought we could change that easily but was not possible. We´ve been > dealing with our lawyers, Alliotts, and finally agreed that signing again > Richard was going to be quicker and easier. I had planned to go to London for > changing it end of july, beginning of august but due to some personal > matters, it was imposible and have had to delay until September. Once we > finish this bank issue, Richard will be removed again. > In any case these are internal issues that don´t affect the PKI itself, these > are administrative tasks, but the fact that Richard is again director in > StartCom UK is just for this matter and has no other responsibility or > function within StartCom. > > > Let me know if you need more clarification or have some other doubts or > questions > > Best regards > > Iñigo Barreira > CEO > StartCom CA Limited > > > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] > On Behalf Of Jakob Bohm via dev-security-policy > Sent: lunes, 7 de agosto de 2017 22:03 > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: StartCom cross-signs disclosed by Certinomis > > On 07/08/2017 11:21, Franck Leroy wrote: > > Hello > > I see many reactions that are not in line with the reality because you > > don’t have all the history on the subject. > > I’ll try to summarize. > > Approximately one year ago Inigo was CTO of Izenpe (CA of the Basque > > Country) and he left this company in order to join StartCom. > > Not long after he arrives at StartCom (days? Weeks? I don’t know) we > > discover the deal that has been made by the previous CEO (Eddy Nigg) with > > the Chinese’s guys and the relations with WoSign. > > Inigo could have resign in regard to the trap the hiring was, but he > > decided to face, and to setup the remediation plan defined by Mozilla > > community. > > As said Jon Snow in S07E01: “I will not punish a son for this father’s > > sins”. > > So instead of denigrate Inigo’s work, as a community we should encourage > > and support him. > > Setting up a new company, with a new datacentre, new pki software, NO > > client, NO revenue, with Chinese employees far away speaking not fluent > > English and with the pressure of the market, it is definitely not an easy > > task! Personally I would not have tried this, so bravo for Inigo’s bravery… > > One of the major thing to solve in addition of the remediation plan was to > > be back in the business as soon as possible, because without any incomes a > > company cannot survive. > > So Inigo contacted me to know if Certinomis could help him to be back in > > the business. As you can imagine we did not said yes immediately. > > But Inigo is not an anonymous guy coming from a strange area of Spain. He > > has been for many years an active CABForum member. He is also an active > > expert at ESTI, where he was
Re: [EXT] Re: Draft further questions for Symantec
The link in footnote [1] https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t000Gmi3AAC=File__Body__s gives me a 404 error. On Monday, May 15, 2017 at 11:09:41 AM UTC-4, Steve Medin wrote: > Gerv, > > Our response to the recent questions is posted at: > https://bugzilla.mozilla.org/attachment.cgi?id=8867735 > > Kind regards, > Steve > > > -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of > > Gervase Markham via dev-security-policy > > Sent: Wednesday, May 10, 2017 7:06 AM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: [EXT] Re: Draft further questions for Symantec > > > > On 08/05/17 13:24, Gervase Markham wrote: > > > 8) Please explain how the Management Assertions for your December 2014 > > > > > > Strike this question; it's based on a misunderstanding of how audits are > > done. > > > > Let's add: > > > > 10) Do you agree that, during the period of time that Symantec cross-signed > > the Federal PKI (Issue L), it was technically possible for issuers inside > > the FPKI > > to issue EV certs by inserting Symantec's EV OID? > > > > 11) If, in the Symantec Issues list or any other document relating to this > > matter we may publish in future, we have drawn a conclusion or inference > > about Symantec's PKI, actions or behaviour which is incorrect, we expect you > > to draw that to our attention, even if the truth is not as favourable to > > Symantec. Are there any incorrect inferences or conclusions in the Issues > > List > > which need to be corrected? > > > > Gerv > > ___ > > 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
Re: April CA Communication: Results
It's useful to note that Outlook 2007 leaves extended support on October 10. (That deadline has been extended a few times, I believe, but this should be the final date.) https://support.microsoft.com/en-us/help/3198497/office-2007-approaching-end-of-extended-support On Monday, May 15, 2017 at 9:16:46 AM UTC-4, Gervase Markham wrote: > On 15/05/17 14:07, Jakob Bohm wrote: > > 1. Microsoft's e-mail clients were very late to accept stronger > > signature algorithms for e-mails (including e-mails sent by users of > > non-problematic e-mail clients). I believe Globalsign's page about > > SHA256-transition for customers provides a nice overview. > > Link? Any docs about research people have done into the prevalance of > SHA-1 for S/MIME, and which clients don't support SHA-256, would be very > useful. > > Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Update
Possibly this is irrelevant, but I have some concerns on how Symantec, it seems to me, is willfully mischaracterizing their certificate compliance issues in their prepared remarks to their investors yesterday.[1] It makes it sound as if there are some generic certificate industry changes that are coming that might affect them. They do not seem willing to accept public responsibility for their actions and compliance failures. "As you may be aware, in late March, Google put forth a proposal that, if implemented, would introduce major changes to the processes and operations that are standard across our industry, including our Certificate Authority business. Since that time, we've been engaged in conversations with Google, Mozilla, and other members of the CA community to seek input on our counter proposal that we believe minimizes business disruption for our customers and improves trust in Symantec's CA business. We believe we will find a mutually agreeable path forward that is in the best interest of our customers, and we expect discussions around our proposal to continue and have factored our current expectations around this headwind into our financial outlook." [1] http://s1.q4cdn.com/585930769/files/doc_financials/2017/Q4/Symantec-4Q17-Prepared-Remarks.pdf On Tuesday, May 9, 2017 at 11:51:33 AM UTC-4, Gervase Markham wrote: > Hi everyone, > > Yesterday was May 8th, which was the day I had said we would stop > discussing my proposal of what to do about Symantec and hand it over to > Kathleen for a decision. This didn't happen for two reasons: I had some > personal things to deal with, and also I think the proposal needs some > modification. > > Mozilla runs an open and transparent root program, and listens to the > voice of its community. And over the past few days it's been clear that > our community is not impressed with Symantec's engagement, or lack > thereof, with this process. I personally am also not impressed with the > way that getting information from Symantec feels like pulling teeth; > questions are answered at the last possible minute, and despite there > being major outstanding problems with compliance to Mozilla's root > program requirements (issue Y), no effort is made from their side to > proactively engage and start to resolve these issues. It is clear from > the issues list that there are a number of serious concerns, and these > are not being engaged with. Despite the fact that there appear to be > numerous under-audited and unaudited publicly-trusted sub-CAs out there, > and this fact has been known for weeks now, Symantec has not said > anything about the situation to Mozilla, either publicly or privately. > Would we find this acceptable in any other CA? > > I am also not happy with simply waiting for the outcome of private > discussions between Google and Symantec in which Mozilla's interests are > not adequately represented. I am keen to move forward, to demonstrate > that delay is not rewarded, and (despite the fact that our process can > be slow) to make sure that timely action is taken based on the results > of our investigations. This is only fair, given that this is what we > have attempted to do for other CAs which we have investigated. We should > treat everyone the same, as far as we can. > > I am therefore proposing the following: > > * Editing the proposal to withdraw the "alternative" option, leaving > only the "new PKI" option. I no longer have confidence that the > alternative option represents an appropriate response. As some have > pointed out, the "documentation" requirement is actually something > Symantec should have done years ago as part of our intermediate > disclosure process, and which other CAs have made great efforts to > comply with already. The "new PKI" option represents the best way to > reduce the risk from Symantec's under-managed and sprawling existing PKI. > > * Engagement here in m.d.s.p. with the community to refine and flesh out > the "new PKI" proposal, based on the Google outline but examining it and > enhancing it to make sure it is practical, both from an implementation > perspective and to reduce disruption to sites as far as possible. > > * Discussions within Mozilla as necessary to make sure the appropriate > parts of the organization are briefed on this process. > > * Submission of the proposal document to Kathleen at the earliest > possible moment to propose that we have that plan approved as our > requirements of Symantec. (The timeline here is dependent on other > moving parts, but as noted above, delay is to be avoided.) > > We may in parallel ask further questions of Symantec, and expect timely > answers (as this is a baseline requirement for participation in our root > program), but this process will not wait around for those answers. > > I will begin work on these tasks tomorrow. > > Gerv ___ dev-security-policy mailing list
Re: Symantec: Draft Proposal
On Monday, May 8, 2017 at 7:21:46 AM UTC-4, okaphone.e...@gmail.com wrote: > Hi Rick, > > I don't see a "May 4th post". Where was it posted? Not here it seems. It's above--it links to https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue > > Also it's reasonable that Symantec wants to "address impact to their > customers" but what about impact to all of the browsers users? It may be a > good idea to try and address (in your proposals) that to. > > So far I have not seen much more than "trust us, we take it seriously and > we'll do it right from now on". But what do you think of Eric's idea? He > seems to suggest a way forward that may be used to turn the whole debacle > into an advantage for you. > > CU Hans > > > On Monday, 8 May 2017 00:09:19 UTC+2, Rick Andrews wrote: > > I'm posting this on behalf of Symantec: > > > > We would like to update the community about our ongoing dialogue with > > Google. > > > > Following our May 4th post, senior executives at Google and Symantec > > established a new dialogue with the intention to arrive at a new proposal > > for the community that addresses the substantial customer impact that would > > result from prior proposals. We urge Symantec customers and the browser > > community to pause on decisions related to this matter until final > > proposals are posted and accepted. The intent of both Google and Symantec > > is to arrive at a proposal that improves security while minimizing business > > disruption across the community. > > > > We want to reassure the community that we are taking these matters and the > > impact on the community very seriously. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft further questions for Symantec
It may be necessary to expand that definition to intermediates that were capable of issuing certificates within the past year (or longer). On Monday, May 8, 2017 at 9:31:21 AM UTC-4, Alex Gaynor wrote: > I'm not the best way to phrase this, so please forgive the bluntness, but I > think it'd be appropriate to ask at this point if Symantec has disclosed > all necessary intermediates (I believe this would be defined as: chain to > their roots in our trust store, are not expired, are not revoked, and are > not technically constrained), and would they be willing to state that if > new intermediate CAs are discovered beyond that point, it would reflect > either dishonesty or serious mismanagement of their PKI. > > Alex > > > On Mon, May 8, 2017 at 9:20 AM, Kurt Roeckx via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On 2017-05-08 14:24, Gervase Markham wrote: > > > >> > >> 1) Did any of the RAs in your program (CrossCert and co.) have the > >> technical ability to independently issue EV certificates? If they did > >> not not, given that they had issuance capability from intermediates > >> which chained up to EV-enabled roots, what technical controls prevented > >> them from having this capability? > >> > > > > It has a duplicate "not" there. > > > > Issue Y > >> --- > >> > >> 3) Does Symantec agree that "VeriSign Class 3 SSP Intermediate CA - G2" > >> and "Symantec Class 3 SSP Intermediate CA - G3", can issue certs which > >> are trusted for SSL/TLS in Mozilla products (by chaining up to "VeriSign > >> Universal Root Certification Authority") and yet do not have BR audits? > >> > > > > I'm wondering if the intermediate CA certificates recently published in CT > > should have it's own issue. As far as I know they should have been > > disclosed much earlier. It seems that (at least now) they're all either > > revoked by CRL on the 5th of May (but not disclosed as revoked) or expired > > except for one (https://crt.sh/?id=132854209). > > > > I think they're all from "VeriSign Class 3 SSP Intermediate CA", not G2 or > > G3, except that one that's not revoked. > > > > 4) These two intermediates have a number of sub-intermediates. Does > >> Symantec agree that not all of these sub-intermediates are within the > >> scope of even Symantec's NFSSP Webtrust for CAs audit?[1] If so, how > >> many are in scope and how many are out of scope? If they are all in > >> scope, why are they not listed in the audit document? > >> > > > > The audit document says: "and the Symantec Non-Federal SSP – customer > > specific CAs (collectively referred to as the “Non-Federal SSP CAs”)." > > > > For which it then says that "our examination did not extend to the > > controls of external registration authorities." > > > > The management assertion also says: > > "Controls have inherent limitations, including the possibility of human > > error and the circumvention or overriding of controls. Accordingly, even > > effective controls can provide only reasonable assurance with respect to > > Symantec’s Non-Federal SSP CA operations. Furthermore, because of changes > > in conditions, the effectiveness of controls may vary over time." > > > > > > Kurt > > > > > > ___ > > 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
Re: Symantec Conclusions and Next Steps
Richard, Did you communicate to your customers over the last 6 months that their existing certificates may become distrusted? Or did they find out when their sites stopped working in Chrome? On Friday, April 28, 2017 at 4:19:01 AM UTC-4, Richard Wang wrote: > Hi Ryan, > > > > For your question “Do you believe that, during the discussions about how to > respond to WoSign's issues, the scope of impact was underestimated?”, the > answer is YES. > > > > After Oct 21 2016, WoSign stopped to issue SSL certificates from WoSign root > (to be exactly, maybe few in October, but all replaced), we know our > customers don’t accept the problem of interoperability and compatibility > failures, so we cooperated with other Trusted CAs to sell their certificates > to our customers since Nov 21 2016, to replace the affected SSL certificates > and code signing certificates for our charged customers for FREE, to renew > and order certificates for current customers and new customers to keep our > business continuity till we have our own new trusted roots. > > > > WoSign appreciated Mozilla’s decision: trust the certificates that issued > before Oct 20 2016, and similarly rule for Apple and Microsoft, and we also > promised to our customers for this, this decision don’t bring any troubles to > our issued certificate customers, very good. > > > > But Google start to distrust WoSign certificates unless the site is in the > Alexa Top 1M site list since Chrome 57, this bring many problems to us and to > our customers, to provide best service to our customers, we provide FREE > replacement for our charged customers that we must pay the cost to the > Partner (Trusted CA). Till now, we replaced 596 certificates for our > customers for free, and there are 97 orders ask for refund instead of > replacement. This Google decision’s problem is some big websites used a > domain that not listed in Alexa 1M suffered disruption, for example, Qihoo > 360’s search site and online gaming sites used a domain in CDN for pictures > that not listed in Top 1M, there are more than 500M users suffered the > untrusted warning and 360 need to replace the certificates for thousands of > servers. > > > > The problem also come from the WoSign Root CA pinned for some payment gateway > from online payment service providers and from some online banking APPs, even > we replaced the certificate for them for free, they need to update the > gateway/API software to accept the new trusted root, and need to update the > bank APP to recognize the new certificate and new root, this is terrible that > all those customers curse us and very angry. > > > > For affected 2417 Code Signing certificates, there are many customers signed > the code, but distrusted by Microsoft that customers ask for full refund and > need to buy the new code signing cert from other CA that need to sign the > software again that installed in billions system, this is also a disaster to > customers and its software users. > > We can’t image the result in the future for “In subsequent Chrome releases, > these exceptions will be reduced and ultimately removed, culminating in the > full distrust of WoSign”, this means all WoSign issued SSL certificates in > the last three years need to be replaced, including the 2845 valid > certificates for Microsoft Azure and Office 365 that Microsoft Sumedh said > “any outage of an Azure service that lasts more than a few minutes gets > escalated to our executives.” > > The total valid SSL certificates is 173,886, and the charged valid > certificates is 10,368 that we need to pay money to other CA for free > replacement (if US$100 per certificate, the total cost is over US$ One > Million!), I think this is not only money problem, but it also will bring > huge work to us and to our customers to replace the certificate. This is the > next BIG disaster if Chrome distrust all WoSign certificates that issued > before Oct. 20 2016. > > > > So, I wish Google can reconsider the plan that change to distrust all WoSign > issued free SSL certificates, but keep to trust the charged one (DV SSL/IV > SSL/OV SSL/EV SSL) that don’t have any mis-issuance problem, those charged > certificates is used for many big eCommerce websites, many government > websites, many bank systems, many securities systems, many cloud service > providers like Azure that used by the world biggest companies. Thanks. > > > > So, this is why I said some words for Symantec to let browsers to consider > the distrust result seriously. The Web Ecosystem players not just browsers, > but also the CAs, and also the website owners (certificate subscribers), we > all have the responsibility for the global Internet security, but we need to > balance all related party’s benefit and negotiate an acceptable solution for > any problem that happened. > > Thanks. > > > > Best Regards, > > > > Richard > > > > From: Ryan Sleevi
Re: SHA-1 serverAuth cert issued by Trustis in November 2016
Is there an expectation of a resolution of some sort to this matter? Also, their most recent audit is apparently overdue (perhaps related to the SHA-1 mis-issuance?) https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/-689uFoXBwAJ On Thursday, March 16, 2017 at 7:00:51 AM UTC-4, Gervase Markham wrote: > Hi Blake, > > On 02/03/17 16:26, blake.mor...@trustis.com wrote: > > We have engaged with our external auditors in relation to this and the > > previous certificate that was reported. Once that activity has concluded we > > will be providing further information. > > Do you have an ETA for this incident report? It's been quite some time > now. I am still interested to understand how a "full investigation" of > the first certificate failed to turn up the second. > > Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Issues doc updated
>Within a few days of discovering these issues they shut down their
>entire RA program. That seems pretty swift and comprehensive to me. The
>fact that they didn't discover these issues for years is clearly a
>problem, but it's not the same problem.
I don't believe that's a fair characterization--looking at
https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content=INFO4154
it was more like "After approximately 3 weeks (Jan 19-Feb 12) they *decided* to
shut down their RA program."
("we have made the decision to terminate our partner RA program. We will
continue to work with select partners that have local market contacts and
expertise to facilitate an interface with customers and collection of relevant
documentation, however Symantec personnel will validate 100% of all asserted
identity data and control certificate issuance going forward. We have
communicated this change to each of our RA partners, we are finalizing a
transition plan, and intend to implement that transition quickly.")
Their latest update (approximately 3 months from the initial report) is that
"Symantec announced the decision to wind down the RA program for publicly
trusted SSL/TLS."
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/dVMxrUVygS0/xeUCJ1kmDQAJ
While Symantec re-validating each issued cert from their RA's is good, and it
appears CrossCert is fully terminated, they clearly have not "shut down their
entire RA program."
On Tuesday, April 11, 2017 at 12:53:56 PM UTC-4, Gervase Markham wrote:
> On 11/04/17 17:34, Ryan Sleevi wrote:
> > Can you clarify what issues you believe this to be related?
>
> That is a fair question. And also hard work to answer :-)
>
> > Given that Symantec has a routine habit of exceeding any reasonable
> > deadline for response, at what point do you believe it is appropriate for
> > the Mozilla Root Store to begin discussing what steps can or should be
> > taken with respect to the documented and supported incidents, which
> > Symantec has not provided counter-factual data?
>
> Yes, fair enough. Rick and Steve: I will be taking Symantec's statements
> to this group as of one week from today as the sum total of what you
> have to say on the subjects under discussion. After that point, we will
> draw conclusions based on the available data and decide on what course
> of action we may take. I hope that by then you will be able to answer my
> 8 questions, and provide responses or comments to any of Ryan's or other
> people's questions that you wish to address.
>
> Kathleen is on vacation this week, and so no decisions could be taken
> until next week at the earliest anyway.
>
> > It's unclear from your remark "Started to draw some conclusions where that
> > is warranted" what you see as the process and next steps. Perhaps you could
> > clarify what you imagine happening next, and on what timeline, to provide
> > clarity both to Symantec and the general population here. I must admit, I'm
> > quite confused as to where things stand, given that many items have
> > conclusions to them.
>
> See above. After one week, I will be taking stock of the assembled
> evidence, and will invite community members also to draw conclusions. I
> will then present a recommendation for what we should do next. As you
> know, Mozilla's process is a little fuzzy around the edges, but Kathleen
> is the final decision maker. (And she doesn't always agree with me :-)
>
> > With respect to the conclusion to Issue T "Symantec's reaction to the
> > discovery of these problems was unarguably swift and comprehensive.", I
> > would disagree with this. Symantec's response was not swift, relative to
> > other CAs that have been informed of issues. It was not comprehensive -
> > Symantec failed to identify the issues until question, and still maintains,
> > in the latest response, that there is a conclusion unsupported by the
> > evidence they have shared with the community. Their timeline for
> > responsiveness was not swift - we're still discussing this specific issue,
> > and it was first reported on Issue T. I would be happy to find evidence of
> > issues from other CAs that demonstrate a more thorough response or a more
> > timely response.
>
> Within a few days of discovering these issues they shut down their
> entire RA program. That seems pretty swift and comprehensive to me. The
> fact that they didn't discover these issues for years is clearly a
> problem, but it's not the same problem.
>
> > With respect to the conclusion to Issue T, "Their case is that WebTrust
> > audit monitoring should have been sufficient," it's unclear if you are
> > agreeing with that conclusion or simply stating Symantec claims.
>
> Stating Symantec's claims.
>
> > With respect to the conclusion to Issue V,
>
> That's not part of my conclusion, that's a quotation from Symantec which
> I need to check the accuracy of with Kathleen.
>
> > "to specifically address the
> >
Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys
I think page 8 of their manual at least partially explains how and what "QuickInvite" is. The whole document is rather interesting... https://www.geotrust.com/geocenter/resources/partnercenter-user-guide.pdf On Saturday, April 1, 2017 at 6:01:23 AM UTC-4, Nick Lamb wrote: > On Friday, 31 March 2017 17:27:34 UTC+1, tarah.s...@gmail.com wrote: > > I'm Tarah. I am the Principal Security Advocate and Senior Director of > > Engineering at Symantec Website Security (the certificate authority. > > Hello Tarah, > > Regular readers of m.d.s.policy will not be surprised that the news media > doesn't do a great job of explaining problems with the Web PKI. > > As so often I have questions, none of which involve kittens or Ferris Bueller > but instead today focus on QuickInvite URLs. > > 1. Symantec's own web site describes "Quick Invite" in several places, I > presume this is the same QuickInvite system you're talking about. It explains > that "The Quick Invite Duration default expiration time is 30 days, but can > be set during the sending of the invite" with a maximum of one year. > Presumably this is simply obsolete documentation, or else it refers to some > other feature under a similar name? If the former, I am happy to provide the > URLs where I found this, are you able to ensure they get updated or removed ? > > 2. What was the designed purpose of the QuickInvite URL / the QuickInvite > system itself ? I appreciate that for you its purpose is very obvious as > you've spent time up to your neck in it, but to me it's still rather opaque. > Let me set out some possible actors in our play, and hopefully you can tell > me which actors arrange for the URL to be sent out, which actors receive it, > and what they can do with it. That last is quite important. If the list I > provide is inadequate feel free to invent more people, just explain what they > do. > > Exam PLE is a small business with a web site, www.example.com > Andrea is the sysadmin at Exam PLE > Betty is Alice's boss, her details are listed in WHOIS for example.com > Catherine is an employee at the CA, Symantec > Jo is an SSL reseller, she offers cheap Symantec certs > Valorie is a seemingly helpful person who answers Andrea's queries on Q > sites > Wendy runs a web hosting business, she runs the servers www.example.com uses ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys
For what it's worth, this is the latest post on facebook from the researcher. https://www.facebook.com/cbyrneiv/posts/10155129935452436 The private key storage issue sounds like a reseller tool, like https://www.thesslstore.com/ssltools/csr-generator.php and he found the private key was stored with the reseller, when he accessed the account. Chris Byrne March 24 at 8:02pm · UPDATED Tuesday March 28th, to clarify some language, and provide additional detail... .. Looks like I don't have to stay quiet about this one anymore... I found out about this problem... and others related to it... back in early 2015. I warned Symantec about it, and worked through some of the issues with them. At the end of it, they asked for a chance to verify how extensive the issue was, and to fix it. We both agreed it would take up to two years to fix, without creating more chaos and causing more damage... and I said yes. I agreed to limited non-disclosure of the issue, unless I felt it was critically necessary, or it would be unethical or irresponsible for me not to disclose (for example, if there were a threat to national security, or I discovered a compromise of a client, or any actual criminal compromise arising from it, etc... etc...). That said, I informed Krebs and a few others about what I had found... and also that I agreed to let them fix it, because it would be less damaging to the world, than exposure would be. It was one of those issues where there's no GOOD choice... but I looked at the damage immediate exposure would cause, vs. a slowly rolling fix over two years... I talked to some of my friends on the grey and black sides of things, and did my own checking, to see if there was any chatter about this anywhere, and I couldn't find any... and I concluded that more harm would be done if I disclosed. Fellow security professional Bobby Kuzma helped me investigate and validate these issues, and he can verify what I state here. I checked a few months later, and they HAD fixed several of the core problems... though not all of them... So I waited, and so did those who I had informed about the problem, and had verified it for themselves... Unfortunately, late in 2015, my cancer recurred, and spread to my lymph nodes... and I've been fighting it ever since, so I haven't kept up with the issue. So... Here's what the post doesn't mention... If you purchased a Symantec certificate (or a cert from any of their associated subsidiaries and partners) through a third party, from at least as far back as early 2013 until recently; their third party certificate generation, management, and retrieval API allowed those certificates... including in some cases private keys generated by third parties... to be retrieved without proper authentication, or in some cases any authentication at all. Unless the third party added proper security around it, all you had to do was click a link sent in email, and you could retrieve a cert, revoke a cert, and re-issue a cert... and for some third party vendors, depending on the type of certificate, and how the certificate was issued, you could also retrieve private keys. Note, this was not just for server certificates for SSL, it also included other certificates, such as personal certificates used for email and other personal encryption. These certs could be requested entirely through the web interface without a separate server issued certificate request, generating both private and public keys, which would then only be protected by a passphrase. Further, even with first party purchase, for some time in some web interfaces, it was possible for properly authenticated users to edit a URL, and at least retrieve information about first party certificates and their owners, and possibly the certs of others. This is because third party data retrieval was not limited to certificates issued by that third party. It was available to anyone by entering the UID of any other user. To clarify... at no time were we able to retrieve private keys directly from Symantec, only from third parties that issued certificates from a web interface without requiring a server generated certificate request. We were able to confirm that these third party weaknesses extended to retreiving, revoking, and reissuing certificates, in some cases without notification to the legitimate certificate holder. In one case, we were also able to reissue a certificate without first explicitly revoking it, and the original certificate continued working for at least 48 hours... We did not test further to see how long it would take for the certificate revocation list to propagate, and we're not pale to prove one way or the other if the organ certificate was revoked or not. It is possible that the certificate was never revoked at all, and another certificate was simply issued, leaving two valid certificates one controlled by the original requestor, and one controlled by the
Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys
https://www.bleepingcomputer.com/news/security/researcher-says-api-flaw-exposed-symantec-certificates-including-private-keys/ Does anyone have further information about this? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Friday, February 17, 2017 at 10:19:06 PM UTC-5, Ryan Sleevi wrote: > On Fri, Feb 17, 2017 at 5:17 PM, urijah--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Friday, February 17, 2017 at 7:50:31 PM UTC-5, uri...@gmail.com wrote: > > > On Friday, February 17, 2017 at 7:23:54 PM UTC-5, Ryan Sleevi wrote: > > > > I have confirmed with CPA > > > > Canada that at during the 2016 and 2017 periods, EY Brazil was not a > > > > licensed WebTrust practitioner, as indicated at [4]. > > > > > > > > [4] > > > > http://www.webtrust.org/licensed-webtrust-practitioners-international/ > > item64419.aspx > > > > > > > > > The footnote at the above makes that a little hard to understand-- > > > > > > "EY refers to a member firm of Ernst & Young Global Limited. Through a > > license with Ernst & Young Global Limited all EY members are licensed to > > provide WebTrust for Certification Authorities services." > > > > Thanks for highlighting this. Indeed, while confirming the list was up to > date, I had missed the footnote. > > > > Additionally "Ernst Young Brazil" was listed as late as March 20, 2016 > > apparently. > > > > https://web-beta.archive.org/web/20160320161225/http://www. > > webtrust.org/licensed-webtrust-practitions-international/item64419.aspx > > > > > The audit was dated 2017/01/24, so the historic status would be irrelevant. Sure. The strange thing to me (and possibly not relevant to this thread) is how both can be true--all E members worldwide are licensed to do WebTrust audits, yet E Brazil was taken *off* the WebTrust list in the latest update. I think http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx and https://web-beta.archive.org/web/20160320161225/http://www.webtrust.org/licensed-webtrust-practitions-international/item64419.aspx are possibly intended to be read differently. The old list giving specific named firms (or branches), by country (but saying it is a list of "global practitioners") the new list giving many fewer firms, but the country listing meaning...where they are active? If WebTrust revamped their approach to licensing, it might be good to know why/how and when. (And I don't see anywhere on their site where they discuss how they license auditors at all.) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Friday, February 17, 2017 at 7:50:31 PM UTC-5, uri...@gmail.com wrote: > On Friday, February 17, 2017 at 7:23:54 PM UTC-5, Ryan Sleevi wrote: > > I have confirmed with CPA > > Canada that at during the 2016 and 2017 periods, EY Brazil was not a > > licensed WebTrust practitioner, as indicated at [4]. > > > > [4] > > http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx > > > The footnote at the above makes that a little hard to understand-- > > "EY refers to a member firm of Ernst & Young Global Limited. Through a > license with Ernst & Young Global Limited all EY members are licensed to > provide WebTrust for Certification Authorities services." Additionally "Ernst Young Brazil" was listed as late as March 20, 2016 apparently. https://web-beta.archive.org/web/20160320161225/http://www.webtrust.org/licensed-webtrust-practitions-international/item64419.aspx ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Friday, February 17, 2017 at 7:23:54 PM UTC-5, Ryan Sleevi wrote: > I have confirmed with CPA > Canada that at during the 2016 and 2017 periods, EY Brazil was not a > licensed WebTrust practitioner, as indicated at [4]. > > [4] > http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx The footnote at the above makes that a little hard to understand-- "EY refers to a member firm of Ernst & Young Global Limited. Through a license with Ernst & Young Global Limited all EY members are licensed to provide WebTrust for Certification Authorities services." ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
