RE: localhost.megasyncloopback.mega.nz private key in client
Hi Hanno, The certificate has been revoked. We're in the process of migrating our email addresses to all be on comodoca.com and the emails for ssl_abuse@ got directed away from the monitored queue we have in place for it. We didn't notice it straight away because there are some other variants of the abuse email addresses which are still active and were still receiving mail. This was corrected and this certificate was revoked after checking the key. Regards Robin Alden Comodo CA Ltd. > -Original Message- > From: Hanno Böck > Sent: 08 August 2018 15:18 > Cc: Alex Cohn ; summern1...@gmail.com; mozilla- > dev-security-policy@lists.mozilla.org; #SSL_ABUSE > > Subject: Re: localhost.megasyncloopback.mega.nz private key in client > > On Sun, 5 Aug 2018 15:23:42 -0500 > Alex Cohn via dev-security-policy > wrote: > > > The certificate [1] in the GitHub link you posted was issued by > > Comodo, not by GeoTrust. The two share a private key, though, so both > > the Comodo and GeoTrust certs should be considered compromised at this > > point. I've added the Comodo-issued cert to several CT logs for > > tracking, and I'm CCing ssl_ab...@comodoca.com for followup. > > As of today this is still unrevoked: > https://crt.sh/?id=630835231=ocsp > > Given Comodo's abuse contact was CCed in this mail I assume they knew > about this since Sunday. Thus we're way past the 24 hour in which they > should revoke it. > > -- > Hanno Böck > https://hboeck.de/ > > mail/jabber: ha...@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: localhost.megasyncloopback.mega.nz private key in client
Also, I'd like to encourage other CAs to comply with Issue 98 pro-actively, even if it is not required. We're already in compliance. -Tim > -Original Message- > From: dev-security-policy On > Behalf Of Tim Hollebeek via dev-security-policy > Sent: Thursday, August 9, 2018 10:26 AM > To: r...@sleevi.com > Cc: Alex Cohn ; mozilla-dev-security- > pol...@lists.mozilla.org; ha...@hboeck.de; ssl_ab...@comodoca.com; > summern1...@gmail.com > Subject: RE: localhost.megasyncloopback.mega.nz private key in client > > Yup, it was Mozilla policy that I was thinking of. Thanks. > > > > I’m sad it didn’t make it into official Mozilla policy, as I thought it was a > pretty > reasonable and non-controversial requirement. I’d support putting it in the > BRs. > > > > -Tim > > > > From: Ryan Sleevi > Sent: Thursday, August 9, 2018 7:15 AM > To: Tim Hollebeek > Cc: Alex Cohn ; ha...@hboeck.de; mozilla-dev- > security-pol...@lists.mozilla.org; ssl_ab...@comodoca.com; > summern1...@gmail.com > Subject: Re: localhost.megasyncloopback.mega.nz private key in client > > > > Unfortunately, that's not correct. The CA/Browser Forum has passed no such > resolution, as can be seen at https://cabforum.org/ballots/ . > > > > I believe you're confusing this with the discussion from > https://github.com/mozilla/pkipolicy/issues/98, which highlighted that the > BRs 4.9.3 requires clear instructions for reporting key compromise. That > language has existed since the BRs 1.3.0 (the conversion to 3647 format). > > > > Alternatively, you may be confusing this discussion with > https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communi > cation , which required CAs to provide a tested email address for a Problem > Reporting Mechanism. However, as captured in Issue 98, this did not result in > a normative change to the CP/CPS. > > > > On Wed, Aug 8, 2018 at 10:22 PM, Tim Hollebeek via dev-security-policy > mailto:dev-security- > pol...@lists.mozilla.org> > wrote: > > IIRC we recently passed a CABF ballot that the CPS must contain instructions > for submitting problem reports in a specific section of its CPS, in an > attempt to > solve problems like this. This winter or early spring, if my memory is > correct. > > -Tim > > > > -Original Message- > > From: dev-security-policy > > > <mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of > > Alex Cohn via dev-security-policy > > Sent: Wednesday, August 8, 2018 4:01 PM > > To: ha...@hboeck.de <mailto:ha...@hboeck.de> > > Cc: mozilla-dev-security-pol...@lists.mozilla.org > > <mailto:mozilla-dev-security-pol...@lists.mozilla.org> ; > > ssl_ab...@comodoca.com <mailto:ssl_ab...@comodoca.com> ; > > summern1...@gmail.com <mailto:summern1...@gmail.com> > > Subject: Re: localhost.megasyncloopback.mega.nz > > <http://localhost.megasyncloopback.mega.nz> private key in client > > > > On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck <mailto:ha...@hboeck.de> > wrote: > > > > > > > > As of today this is still unrevoked: > > > https://crt.sh/?id=630835231 <https://crt.sh/?id=630835231=ocsp> > > > =ocsp > > > > > > Given Comodo's abuse contact was CCed in this mail I assume they > > > knew about this since Sunday. Thus we're way past the 24 hour in > > > which they should revoke it. > > > > > > -- > > > Hanno Böck > > > https://hboeck.de/ > > > > > > As Hanno has no doubt learned, the ssl_ab...@comodoca.com > > <mailto:ssl_ab...@comodoca.com> address bounces. > > I got that address off of Comodo CA's website at > > https://www.comodoca.com/en-us/support/report-abuse/. > > > > I later found the address "sslab...@comodo.com > > <mailto:sslab...@comodo.com> " in Comodo's latest CPS, and forwarded > > my last message to it on 2018-08-05 at 20:32 CDT (UTC-5). I received > > an automated confirmation immediately afterward, so I assume Comodo > has now known about this issue for ~70 hours now. > > > > crt.sh lists sslab...@comodoca.com <mailto:sslab...@comodoca.com> > as > > the "problem reporting" address for the cert in question. I have not tried > > this > address. > > > > Comodo publishes at least three different problem reporting email > > addresses, and at least one of them is nonfunctional. I think similar > > issues have come up before - there's often not a clear way to identify > > how to contact a CA. Should we re
RE: localhost.megasyncloopback.mega.nz private key in client
Yup, it was Mozilla policy that I was thinking of. Thanks. I’m sad it didn’t make it into official Mozilla policy, as I thought it was a pretty reasonable and non-controversial requirement. I’d support putting it in the BRs. -Tim From: Ryan Sleevi Sent: Thursday, August 9, 2018 7:15 AM To: Tim Hollebeek Cc: Alex Cohn ; ha...@hboeck.de; mozilla-dev-security-pol...@lists.mozilla.org; ssl_ab...@comodoca.com; summern1...@gmail.com Subject: Re: localhost.megasyncloopback.mega.nz private key in client Unfortunately, that's not correct. The CA/Browser Forum has passed no such resolution, as can be seen at https://cabforum.org/ballots/ . I believe you're confusing this with the discussion from https://github.com/mozilla/pkipolicy/issues/98, which highlighted that the BRs 4.9.3 requires clear instructions for reporting key compromise. That language has existed since the BRs 1.3.0 (the conversion to 3647 format). Alternatively, you may be confusing this discussion with https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication , which required CAs to provide a tested email address for a Problem Reporting Mechanism. However, as captured in Issue 98, this did not result in a normative change to the CP/CPS. On Wed, Aug 8, 2018 at 10:22 PM, Tim Hollebeek via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: IIRC we recently passed a CABF ballot that the CPS must contain instructions for submitting problem reports in a specific section of its CPS, in an attempt to solve problems like this. This winter or early spring, if my memory is correct. -Tim > -Original Message- > From: dev-security-policy <mailto:dev-security-policy-boun...@lists.mozilla.org> > On > Behalf Of Alex Cohn via dev-security-policy > Sent: Wednesday, August 8, 2018 4:01 PM > To: ha...@hboeck.de <mailto:ha...@hboeck.de> > Cc: mozilla-dev-security-pol...@lists.mozilla.org > <mailto:mozilla-dev-security-pol...@lists.mozilla.org> ; > ssl_ab...@comodoca.com <mailto:ssl_ab...@comodoca.com> ; > summern1...@gmail.com <mailto:summern1...@gmail.com> > Subject: Re: localhost.megasyncloopback.mega.nz > <http://localhost.megasyncloopback.mega.nz> private key in client > > On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck <mailto:ha...@hboeck.de> > wrote: > > > > > As of today this is still unrevoked: > > https://crt.sh/?id=630835231 <https://crt.sh/?id=630835231=ocsp> > > =ocsp > > > > Given Comodo's abuse contact was CCed in this mail I assume they knew > > about this since Sunday. Thus we're way past the 24 hour in which they > > should revoke it. > > > > -- > > Hanno Böck > > https://hboeck.de/ > > > As Hanno has no doubt learned, the ssl_ab...@comodoca.com > <mailto:ssl_ab...@comodoca.com> address > bounces. > I got that address off of Comodo CA's website at > https://www.comodoca.com/en-us/support/report-abuse/. > > I later found the address "sslab...@comodo.com <mailto:sslab...@comodo.com> " > in Comodo's latest CPS, > and forwarded my last message to it on 2018-08-05 at 20:32 CDT (UTC-5). I > received an automated confirmation immediately afterward, so I assume > Comodo has now known about this issue for ~70 hours now. > > crt.sh lists sslab...@comodoca.com <mailto:sslab...@comodoca.com> as the > "problem reporting" address for > the cert in question. I have not tried this address. > > Comodo publishes at least three different problem reporting email addresses, > and at least one of them is nonfunctional. I think similar issues have come up > before - there's often not a clear way to identify how to contact a CA. Should > we revisit the topic? > > Alex > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > <mailto: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 <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: localhost.megasyncloopback.mega.nz private key in client
+Adding Robin Alden and Richard Smith -Original Message- From: Hanno Böck Sent: Thursday, August 09, 2018 10:51 AM To: Jay Wilson via dev-security-policy Cc: Jay Wilson ; Alex Cohn ; ssl_ab...@comodo.com; mozilla-dev-security-pol...@lists.mozilla.org; summern1...@gmail.com Subject: Re: localhost.megasyncloopback.mega.nz private key in client On Thu, 9 Aug 2018 13:24:48 + Jay Wilson via dev-security-policy wrote: > The certificate has been revoked. > The bounce issue has been escalated to resolve. Really? $ ocspverify 630835231.crt Response verify OK 630835231.crt: good This Update: Aug 4 15:34:50 2018 GMT Next Update: Aug 11 15:34:50 2018 GMT crt.sh also says "Good" on OCSP: https://crt.sh/?id=630835231=ocsp -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: localhost.megasyncloopback.mega.nz private key in client
On Thu, 9 Aug 2018 13:24:48 + Jay Wilson via dev-security-policy wrote: > The certificate has been revoked. > The bounce issue has been escalated to resolve. Really? $ ocspverify 630835231.crt Response verify OK 630835231.crt: good This Update: Aug 4 15:34:50 2018 GMT Next Update: Aug 11 15:34:50 2018 GMT crt.sh also says "Good" on OCSP: https://crt.sh/?id=630835231=ocsp -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: localhost.megasyncloopback.mega.nz private key in client
The proposed "Revocation Timeline Extension" ballot (formerly #213, soon to become #SC6) [1] includes the following: The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS. - Wayne [1] https://github.com/cabforum/documents/compare/master...wthayer:patch-1?short_path=7f6d14a#diff-7f6d14a20e7f3beb696b45e1bf8196f2 On Thu, Aug 9, 2018 at 7:41 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Unfortunately, that's not correct. The CA/Browser Forum has passed no such > resolution, as can be seen at https://cabforum.org/ballots/ . > > I believe you're confusing this with the discussion from > https://github.com/mozilla/pkipolicy/issues/98, which highlighted that the > BRs 4.9.3 requires clear instructions for reporting key compromise. That > language has existed since the BRs 1.3.0 (the conversion to 3647 format). > > Alternatively, you may be confusing this discussion with > https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication > , > which required CAs to provide a tested email address for a Problem > Reporting Mechanism. However, as captured in Issue 98, this did not result > in a normative change to the CP/CPS. > > On Wed, Aug 8, 2018 at 10:22 PM, Tim Hollebeek via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > IIRC we recently passed a CABF ballot that the CPS must contain > > instructions > > for submitting problem reports in a specific section of its CPS, in an > > attempt > > to solve problems like this. This winter or early spring, if my memory > is > > correct. > > > > -Tim > > > > > -Original Message- > > > From: dev-security-policy < > dev-security-policy-boun...@lists.mozilla.org> > > On > > > Behalf Of Alex Cohn via dev-security-policy > > > Sent: Wednesday, August 8, 2018 4:01 PM > > > To: ha...@hboeck.de > > > Cc: mozilla-dev-security-pol...@lists.mozilla.org; > > ssl_ab...@comodoca.com; > > > summern1...@gmail.com > > > Subject: Re: localhost.megasyncloopback.mega.nz private key in client > > > > > > On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck wrote: > > > > > > > > > > > As of today this is still unrevoked: > > > > https://crt.sh/?id=630835231=ocsp > > > > > > > > Given Comodo's abuse contact was CCed in this mail I assume they knew > > > > about this since Sunday. Thus we're way past the 24 hour in which > they > > > > should revoke it. > > > > > > > > -- > > > > Hanno Böck > > > > https://hboeck.de/ > > > > > > > > > As Hanno has no doubt learned, the ssl_ab...@comodoca.com address > > > bounces. > > > I got that address off of Comodo CA's website at > > > https://www.comodoca.com/en-us/support/report-abuse/. > > > > > > I later found the address "sslab...@comodo.com" in Comodo's latest > CPS, > > > and forwarded my last message to it on 2018-08-05 at 20:32 CDT > (UTC-5). I > > > received an automated confirmation immediately afterward, so I assume > > > Comodo has now known about this issue for ~70 hours now. > > > > > > crt.sh lists sslab...@comodoca.com as the "problem reporting" address > > for > > > the cert in question. I have not tried this address. > > > > > > Comodo publishes at least three different problem reporting email > > addresses, > > > and at least one of them is nonfunctional. I think similar issues have > > come up > > > before - there's often not a clear way to identify how to contact a CA. > > Should > > > we revisit the topic? > > > > > > Alex > > > ___ > > > 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 > > > > > ___ > 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: localhost.megasyncloopback.mega.nz private key in client
+Adding Robin Alden and Richard Smith From: Ryan Sleevi Sent: Thursday, August 09, 2018 8:15 AM To: Tim Hollebeek Cc: Alex Cohn ; ha...@hboeck.de; mozilla-dev-security-pol...@lists.mozilla.org; #SSL_ABUSE ; summern1...@gmail.com Subject: Re: localhost.megasyncloopback.mega.nz private key in client Unfortunately, that's not correct. The CA/Browser Forum has passed no such resolution, as can be seen at https://cabforum.org/ballots/ . I believe you're confusing this with the discussion from https://github.com/mozilla/pkipolicy/issues/98, which highlighted that the BRs 4.9.3 requires clear instructions for reporting key compromise. That language has existed since the BRs 1.3.0 (the conversion to 3647 format). Alternatively, you may be confusing this discussion with https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication , which required CAs to provide a tested email address for a Problem Reporting Mechanism. However, as captured in Issue 98, this did not result in a normative change to the CP/CPS. On Wed, Aug 8, 2018 at 10:22 PM, Tim Hollebeek via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: IIRC we recently passed a CABF ballot that the CPS must contain instructions for submitting problem reports in a specific section of its CPS, in an attempt to solve problems like this. This winter or early spring, if my memory is correct. -Tim > -Original Message- > From: dev-security-policy > mailto:dev-security-policy-boun...@lists.mozilla.org>> > On > Behalf Of Alex Cohn via dev-security-policy > Sent: Wednesday, August 8, 2018 4:01 PM > To: ha...@hboeck.de<mailto:ha...@hboeck.de> > Cc: > mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>; > ssl_ab...@comodoca.com<mailto:ssl_ab...@comodoca.com>; > summern1...@gmail.com<mailto:summern1...@gmail.com> > Subject: Re: > localhost.megasyncloopback.mega.nz<http://localhost.megasyncloopback.mega.nz> > private key in client > > On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck > mailto:ha...@hboeck.de>> wrote: > > > > > As of today this is still unrevoked: > > https://crt.sh/?id=630835231=ocsp > > > > Given Comodo's abuse contact was CCed in this mail I assume they knew > > about this since Sunday. Thus we're way past the 24 hour in which they > > should revoke it. > > > > -- > > Hanno Böck > > https://hboeck.de/ > > > As Hanno has no doubt learned, the > ssl_ab...@comodoca.com<mailto:ssl_ab...@comodoca.com> address > bounces. > I got that address off of Comodo CA's website at > https://www.comodoca.com/en-us/support/report-abuse/. > > I later found the address "sslab...@comodo.com<mailto:sslab...@comodo.com>" > in Comodo's latest CPS, > and forwarded my last message to it on 2018-08-05 at 20:32 CDT (UTC-5). I > received an automated confirmation immediately afterward, so I assume > Comodo has now known about this issue for ~70 hours now. > > crt.sh lists sslab...@comodoca.com<mailto:sslab...@comodoca.com> as the > "problem reporting" address for > the cert in question. I have not tried this address. > > Comodo publishes at least three different problem reporting email addresses, > and at least one of them is nonfunctional. I think similar issues have come up > before - there's often not a clear way to identify how to contact a CA. Should > we revisit the topic? > > Alex > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org<mailto: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<mailto: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: localhost.megasyncloopback.mega.nz private key in client
The certificate has been revoked. The bounce issue has been escalated to resolve. Regards, From: Alex Cohn Sent: Wednesday, August 08, 2018 5:01 PM To: ha...@hboeck.de Cc: summern1...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org; #SSL_ABUSE Subject: Re: localhost.megasyncloopback.mega.nz private key in client On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck mailto:ha...@hboeck.de>> wrote: As of today this is still unrevoked: https://crt.sh/?id=630835231=ocsp Given Comodo's abuse contact was CCed in this mail I assume they knew about this since Sunday. Thus we're way past the 24 hour in which they should revoke it. -- Hanno Böck https://hboeck.de/ As Hanno has no doubt learned, the ssl_ab...@comodoca.com<mailto:ssl_ab...@comodoca.com> address bounces. I got that address off of Comodo CA's website at https://www.comodoca.com/en-us/support/report-abuse/. I later found the address "sslab...@comodo.com<mailto:sslab...@comodo.com>" in Comodo's latest CPS, and forwarded my last message to it on 2018-08-05 at 20:32 CDT (UTC-5). I received an automated confirmation immediately afterward, so I assume Comodo has now known about this issue for ~70 hours now. crt.sh lists sslab...@comodoca.com<mailto:sslab...@comodoca.com> as the "problem reporting" address for the cert in question. I have not tried this address. Comodo publishes at least three different problem reporting email addresses, and at least one of them is nonfunctional. I think similar issues have come up before - there's often not a clear way to identify how to contact a CA. Should we revisit the topic? Alex ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: localhost.megasyncloopback.mega.nz private key in client
Unfortunately, that's not correct. The CA/Browser Forum has passed no such resolution, as can be seen at https://cabforum.org/ballots/ . I believe you're confusing this with the discussion from https://github.com/mozilla/pkipolicy/issues/98, which highlighted that the BRs 4.9.3 requires clear instructions for reporting key compromise. That language has existed since the BRs 1.3.0 (the conversion to 3647 format). Alternatively, you may be confusing this discussion with https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication , which required CAs to provide a tested email address for a Problem Reporting Mechanism. However, as captured in Issue 98, this did not result in a normative change to the CP/CPS. On Wed, Aug 8, 2018 at 10:22 PM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > IIRC we recently passed a CABF ballot that the CPS must contain > instructions > for submitting problem reports in a specific section of its CPS, in an > attempt > to solve problems like this. This winter or early spring, if my memory is > correct. > > -Tim > > > -Original Message- > > From: dev-security-policy > On > > Behalf Of Alex Cohn via dev-security-policy > > Sent: Wednesday, August 8, 2018 4:01 PM > > To: ha...@hboeck.de > > Cc: mozilla-dev-security-pol...@lists.mozilla.org; > ssl_ab...@comodoca.com; > > summern1...@gmail.com > > Subject: Re: localhost.megasyncloopback.mega.nz private key in client > > > > On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck wrote: > > > > > > > > As of today this is still unrevoked: > > > https://crt.sh/?id=630835231=ocsp > > > > > > Given Comodo's abuse contact was CCed in this mail I assume they knew > > > about this since Sunday. Thus we're way past the 24 hour in which they > > > should revoke it. > > > > > > -- > > > Hanno Böck > > > https://hboeck.de/ > > > > > > As Hanno has no doubt learned, the ssl_ab...@comodoca.com address > > bounces. > > I got that address off of Comodo CA's website at > > https://www.comodoca.com/en-us/support/report-abuse/. > > > > I later found the address "sslab...@comodo.com" in Comodo's latest CPS, > > and forwarded my last message to it on 2018-08-05 at 20:32 CDT (UTC-5). I > > received an automated confirmation immediately afterward, so I assume > > Comodo has now known about this issue for ~70 hours now. > > > > crt.sh lists sslab...@comodoca.com as the "problem reporting" address > for > > the cert in question. I have not tried this address. > > > > Comodo publishes at least three different problem reporting email > addresses, > > and at least one of them is nonfunctional. I think similar issues have > come up > > before - there's often not a clear way to identify how to contact a CA. > Should > > we revisit the topic? > > > > Alex > > ___ > > 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 > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: localhost.megasyncloopback.mega.nz private key in client
IIRC we recently passed a CABF ballot that the CPS must contain instructions for submitting problem reports in a specific section of its CPS, in an attempt to solve problems like this. This winter or early spring, if my memory is correct. -Tim > -Original Message- > From: dev-security-policy On > Behalf Of Alex Cohn via dev-security-policy > Sent: Wednesday, August 8, 2018 4:01 PM > To: ha...@hboeck.de > Cc: mozilla-dev-security-pol...@lists.mozilla.org; ssl_ab...@comodoca.com; > summern1...@gmail.com > Subject: Re: localhost.megasyncloopback.mega.nz private key in client > > On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck wrote: > > > > > As of today this is still unrevoked: > > https://crt.sh/?id=630835231=ocsp > > > > Given Comodo's abuse contact was CCed in this mail I assume they knew > > about this since Sunday. Thus we're way past the 24 hour in which they > > should revoke it. > > > > -- > > Hanno Böck > > https://hboeck.de/ > > > As Hanno has no doubt learned, the ssl_ab...@comodoca.com address > bounces. > I got that address off of Comodo CA's website at > https://www.comodoca.com/en-us/support/report-abuse/. > > I later found the address "sslab...@comodo.com" in Comodo's latest CPS, > and forwarded my last message to it on 2018-08-05 at 20:32 CDT (UTC-5). I > received an automated confirmation immediately afterward, so I assume > Comodo has now known about this issue for ~70 hours now. > > crt.sh lists sslab...@comodoca.com as the "problem reporting" address for > the cert in question. I have not tried this address. > > Comodo publishes at least three different problem reporting email addresses, > and at least one of them is nonfunctional. I think similar issues have come up > before - there's often not a clear way to identify how to contact a CA. Should > we revisit the topic? > > Alex > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: localhost.megasyncloopback.mega.nz private key in client
On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck wrote: > > As of today this is still unrevoked: > https://crt.sh/?id=630835231=ocsp > > Given Comodo's abuse contact was CCed in this mail I assume they knew > about this since Sunday. Thus we're way past the 24 hour in which they > should revoke it. > > -- > Hanno Böck > https://hboeck.de/ As Hanno has no doubt learned, the ssl_ab...@comodoca.com address bounces. I got that address off of Comodo CA's website at https://www.comodoca.com/en-us/support/report-abuse/. I later found the address "sslab...@comodo.com" in Comodo's latest CPS, and forwarded my last message to it on 2018-08-05 at 20:32 CDT (UTC-5). I received an automated confirmation immediately afterward, so I assume Comodo has now known about this issue for ~70 hours now. crt.sh lists sslab...@comodoca.com as the "problem reporting" address for the cert in question. I have not tried this address. Comodo publishes at least three different problem reporting email addresses, and at least one of them is nonfunctional. I think similar issues have come up before - there's often not a clear way to identify how to contact a CA. Should we revisit the topic? Alex ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: localhost.megasyncloopback.mega.nz private key in client
On Sun, 5 Aug 2018 15:23:42 -0500 Alex Cohn via dev-security-policy wrote: > The certificate [1] in the GitHub link you posted was issued by > Comodo, not by GeoTrust. The two share a private key, though, so both > the Comodo and GeoTrust certs should be considered compromised at > this point. I've added the Comodo-issued cert to several CT logs for > tracking, and I'm CCing ssl_ab...@comodoca.com for followup. As of today this is still unrevoked: https://crt.sh/?id=630835231=ocsp Given Comodo's abuse contact was CCed in this mail I assume they knew about this since Sunday. Thus we're way past the 24 hour in which they should revoke it. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: localhost.megasyncloopback.mega.nz private key in client
The certificate [1] in the GitHub link you posted was issued by Comodo, not by GeoTrust. The two share a private key, though, so both the Comodo and GeoTrust certs should be considered compromised at this point. I've added the Comodo-issued cert to several CT logs for tracking, and I'm CCing ssl_ab...@comodoca.com for followup. I've also found the final GeoTrust cert [2] in the git revision history and logged it (you had linked to the precertificate). According to OCSP, DigiCert has revoked the GeoTrust certificate as of 2018-08-04 07:13:32 UTC. Alex [1]: https://censys.io/certificates/04db0e79f2aa22d91f66fdea2b03193b04d1987b5ae5f3b5ce326e9539bde550 [2]: https://censys.io/certificates/de549fa946e0564e4d50f21ced16035f1dc25be26099a7add70d55efb39d5811 On Thu, Aug 2, 2018 at 11:07 PM summern1538--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello Ben, > > Thanks for your fast response and help. > > After a bit research I also found the source with the key: > > https://github.com/meganz/MEGAsync/blob/master/src/MEGASync/control/Preferences.cpp > > As it is public I think it should not be problem to post it here. > > Best Regards > Norbert > ___ > 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: localhost.megasyncloopback.mega.nz private key in client
Hello Ben, Thanks for your fast response and help. After a bit research I also found the source with the key: https://github.com/meganz/MEGAsync/blob/master/src/MEGASync/control/Preferences.cpp As it is public I think it should not be problem to post it here. Best Regards Norbert ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: localhost.megasyncloopback.mega.nz private key in client
Norbert, I've tried to verify this with and without spaces in the msg.asc below. I get "Signature Verification Failure". Please contact me off-list to provide me clearer information related to your proof of private key possession. Thanks, Ben Wilson -Original Message- From: dev-security-policy On Behalf Of summern1538--- via dev-security-policy Sent: Thursday, August 2, 2018 4:06 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: localhost.megasyncloopback.mega.nz private key in client Hello everyone, I'm not sure where to report this issue, this is my fist cert issue report. I tried to report it to GeoTrust, but they don't know about this domain. Replay from GeoTrust > Good day, > > Thank you very much for the friendly request. > > Unfortunately I was not able to find anything for the provided Domain localhost.megasyncloopback.mega.nz in our records. I'm also not sure what is the difference from RapidSSL and GeoTrust. ## Affected certificate: https://clicktime.symantec.com/a/1/Y-bjBMElqYp0KwPlm3OjZXUTkdVJDsIqjXFYgZhQa aY=?d=MgL9dpfm4sY-fi4UP-itDohKjJyuuFPnW2-lyzRErTErGtuNlmb-TdlrMvR7Vzqmu0LJHx YnLwBpQQI_w9UKOT-1jgPA-YDbaS2QaTIGNCKpZnCH91Q9RHiVH-Wz0P8ugpWF2ygRb442WoABFb 9W-AzK2ATlQ4b_JJJwHZxoIz_5L48rEGNkHhagvyOTJYOIwa_KSmBRd-1DMWTNKpEX8y_FcGWEix r-_8WJLSMWnBQEzUp7dJBcMwQhU1sgzxZV0bKJYFCkGeukWPTptwwc6UTQ7yjxx-pgBdcbqNArTG FZYqas7evKXRU7OmEH22VdY5pNqZHlQFCA14KSVNRIy5vGqjc2VnCiGRHYRHMP0xK9SevGSNF63A sbjGSk1KxbOFgwEn9SLkoNsvf37Qnw_hi9q6seQyIzCmsmr9WshXfn8Ln_Qp_pgD3jjxgGR-qG1Y lEQbcIuHCsJOR2NNdkHn4R=https%3A%2F%2Fcensys.io%2Fcertificates%2F87d92f12e1 fa4ab0a1460834067d161d085c013d14ca98489c807ce40521b981 https://clicktime.symantec.com/a/1/Ytht2fzBFvZghjVVypfCTp53dGvjsKwwh4w7tgJap to=?d=MgL9dpfm4sY-fi4UP-itDohKjJyuuFPnW2-lyzRErTErGtuNlmb-TdlrMvR7Vzqmu0LJHx YnLwBpQQI_w9UKOT-1jgPA-YDbaS2QaTIGNCKpZnCH91Q9RHiVH-Wz0P8ugpWF2ygRb442WoABFb 9W-AzK2ATlQ4b_JJJwHZxoIz_5L48rEGNkHhagvyOTJYOIwa_KSmBRd-1DMWTNKpEX8y_FcGWEix r-_8WJLSMWnBQEzUp7dJBcMwQhU1sgzxZV0bKJYFCkGeukWPTptwwc6UTQ7yjxx-pgBdcbqNArTG FZYqas7evKXRU7OmEH22VdY5pNqZHlQFCA14KSVNRIy5vGqjc2VnCiGRHYRHMP0xK9SevGSNF63A sbjGSk1KxbOFgwEn9SLkoNsvf37Qnw_hi9q6seQyIzCmsmr9WshXfn8Ln_Qp_pgD3jjxgGR-qG1Y lEQbcIuHCsJOR2NNdkHn4R=https%3A%2F%2Fcrt.sh%2F%3Fid%3D112840296 ## Background: Mega.nz has a sync client, that starts a HTTPS server on port 6342. Whenever you visit a site on `mega.nz`, the browser tries to connect to `https://clicktime.symantec.com/a/1/zJ35w_Pu7bpe0t2m0GRsF2ePu0VsvDNruXgyii0T bDs=?d=MgL9dpfm4sY-fi4UP-itDohKjJyuuFPnW2-lyzRErTErGtuNlmb-TdlrMvR7Vzqmu0LJH xYnLwBpQQI_w9UKOT-1jgPA-YDbaS2QaTIGNCKpZnCH91Q9RHiVH-Wz0P8ugpWF2ygRb442WoABF b9W-AzK2ATlQ4b_JJJwHZxoIz_5L48rEGNkHhagvyOTJYOIwa_KSmBRd-1DMWTNKpEX8y_FcGWEi xr-_8WJLSMWnBQEzUp7dJBcMwQhU1sgzxZV0bKJYFCkGeukWPTptwwc6UTQ7yjxx-pgBdcbqNArT GFZYqas7evKXRU7OmEH22VdY5pNqZHlQFCA14KSVNRIy5vGqjc2VnCiGRHYRHMP0xK9SevGSNF63 AsbjGSk1KxbOFgwEn9SLkoNsvf37Qnw_hi9q6seQyIzCmsmr9WshXfn8Ln_Qp_pgD3jjxgGR-qG1 YlEQbcIuHCsJOR2NNdkHn4R=https%3A%2F%2Flocalhost.megasyncloopback.mega.nz%3 A6342%2F`. Obviously the client need the private key to start that HTTPS server. After a bit debugging from the client, I was able to recover the private key from that certificate. ## Proof: msg: (msg.txt) TW9uIEp1bCAyMyAxMzo1ODo1MiBDRVNUIDIwMTgKClBsZWFzZSByZXZva2UK rsa signatur: (msg.asc) VzijbZMHptbIdgOAACSeVLGLKyESeFK4aAKxOS3i/shHDSp53RJJJS0kbeOq7YDCrccqT6gaNXMa 46bcFxUvvwcYwQox6bh6s0+R+PHDgt0LVqutUJUlPLvOC9vDRHCy29hPMf6wXQckvy90KUvwkc2P tb0GzFfH94DjjQxPfMWwEEZeyUvp2v+KcbFHQNwJp0UKFrfUWW5ooFTZA7E3EeHynW6sHCJS+r64 R5tUdrGGTh1ee6KRrBxOK1qXJVCRF2ftrwXo7rMYUf4MqWCntpD0YMZVkJ5j8VMKx3iVjcq+p++b boDqCxaUEnHvY96UMrbsrv/z2rWY2V0oVoAZeA== To proof decode the base64 to the files in the braket (): Extract the pubkey from the cert: `$ openssl x509 -in 112840296.crt -pubkey -noout > pub.pem` and run the following command to verify the message: `$ openssl pkeyutl -verify -pubin -inkey pub.pem -in msg.txt -sigfile msg.asc` Is there an easy way to create a cert revoke from the private key? How to revoke the certificate? Best Regards Norbert Summer certificate as pem (112840296.crt): -BEGIN CERTIFICATE- MIIElTCCA32gAwIBAgIQL41amoCH4B2agSUpD8Wd2DANBgkqhkiG9w0BAQsFADBC MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UEAxMS UmFwaWRTU0wgU0hBMjU2IENBMB4XDTE3MDQwNTAwMDAwMFoXDTE5MDcwNTIzNTk1 OVowLTErMCkGA1UEAwwibG9jYWxob3N0Lm1lZ2FzeW5jbG9vcGJhY2subWVnYS5u ejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALGT0FSySDLZ0c252+vO qyPfrXhSeJeMDDeyQw/7FRQsGBpNwaBCRhEwzojuuj/1GimrnKkrmnxyZSpNiG7/ 1nhE/9qwcMgwLuUioi+ChldBZ0kcCEn0oGCdiL6NA3RDohAFp31ZH90oxy6Wc3Sg zKfzas72jBXjt1hXN1Cc8TWTXPUerMrKqsGMe8Z9JDIwDZgK5KXUrcTNBjw0Vhd6 7dmPAUI++4OZGkuqSAoGu/Ac+7TNpA3taWI0HP7wmcG3o9Q029NnTL+JhRFPeThI eWGL/Fd1X2OqMA3jfdEwisYhakWcGgmlpMVtOxTfPo2PkFT9NhCloE6J6JN87bVp yXsCAwEAAaOCAZowggGWMC0GA1UdEQQmMCSCImxvY2FsaG9zdC5tZWdhc3luY2xv b3BiYWNrLm1lZ2EubnowCQYDVR0TBAIwADAr
localhost.megasyncloopback.mega.nz private key in client
Hello everyone, I'm not sure where to report this issue, this is my fist cert issue report. I tried to report it to GeoTrust, but they don't know about this domain. Replay from GeoTrust > Good day, > > Thank you very much for the friendly request. > > Unfortunately I was not able to find anything for the provided Domain > localhost.megasyncloopback.mega.nz in our records. I'm also not sure what is the difference from RapidSSL and GeoTrust. ## Affected certificate: https://censys.io/certificates/87d92f12e1fa4ab0a1460834067d161d085c013d14ca98489c807ce40521b981 https://crt.sh/?id=112840296 ## Background: Mega.nz has a sync client, that starts a HTTPS server on port 6342. Whenever you visit a site on `mega.nz`, the browser tries to connect to `https://localhost.megasyncloopback.mega.nz:6342/`. Obviously the client need the private key to start that HTTPS server. After a bit debugging from the client, I was able to recover the private key from that certificate. ## Proof: msg: (msg.txt) TW9uIEp1bCAyMyAxMzo1ODo1MiBDRVNUIDIwMTgKClBsZWFzZSByZXZva2UK rsa signatur: (msg.asc) VzijbZMHptbIdgOAACSeVLGLKyESeFK4aAKxOS3i/shHDSp53RJJJS0kbeOq7YDCrccqT6gaNXMa 46bcFxUvvwcYwQox6bh6s0+R+PHDgt0LVqutUJUlPLvOC9vDRHCy29hPMf6wXQckvy90KUvwkc2P tb0GzFfH94DjjQxPfMWwEEZeyUvp2v+KcbFHQNwJp0UKFrfUWW5ooFTZA7E3EeHynW6sHCJS+r64 R5tUdrGGTh1ee6KRrBxOK1qXJVCRF2ftrwXo7rMYUf4MqWCntpD0YMZVkJ5j8VMKx3iVjcq+p++b boDqCxaUEnHvY96UMrbsrv/z2rWY2V0oVoAZeA== To proof decode the base64 to the files in the braket (): Extract the pubkey from the cert: `$ openssl x509 -in 112840296.crt -pubkey -noout > pub.pem` and run the following command to verify the message: `$ openssl pkeyutl -verify -pubin -inkey pub.pem -in msg.txt -sigfile msg.asc` Is there an easy way to create a cert revoke from the private key? How to revoke the certificate? Best Regards Norbert Summer certificate as pem (112840296.crt): -BEGIN CERTIFICATE- MIIElTCCA32gAwIBAgIQL41amoCH4B2agSUpD8Wd2DANBgkqhkiG9w0BAQsFADBC MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UEAxMS UmFwaWRTU0wgU0hBMjU2IENBMB4XDTE3MDQwNTAwMDAwMFoXDTE5MDcwNTIzNTk1 OVowLTErMCkGA1UEAwwibG9jYWxob3N0Lm1lZ2FzeW5jbG9vcGJhY2subWVnYS5u ejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALGT0FSySDLZ0c252+vO qyPfrXhSeJeMDDeyQw/7FRQsGBpNwaBCRhEwzojuuj/1GimrnKkrmnxyZSpNiG7/ 1nhE/9qwcMgwLuUioi+ChldBZ0kcCEn0oGCdiL6NA3RDohAFp31ZH90oxy6Wc3Sg zKfzas72jBXjt1hXN1Cc8TWTXPUerMrKqsGMe8Z9JDIwDZgK5KXUrcTNBjw0Vhd6 7dmPAUI++4OZGkuqSAoGu/Ac+7TNpA3taWI0HP7wmcG3o9Q029NnTL+JhRFPeThI eWGL/Fd1X2OqMA3jfdEwisYhakWcGgmlpMVtOxTfPo2PkFT9NhCloE6J6JN87bVp yXsCAwEAAaOCAZowggGWMC0GA1UdEQQmMCSCImxvY2FsaG9zdC5tZWdhc3luY2xv b3BiYWNrLm1lZ2EubnowCQYDVR0TBAIwADArBgNVHR8EJDAiMCCgHqAchhpodHRw Oi8vZ3Auc3ltY2IuY29tL2dwLmNybDBvBgNVHSAEaDBmMGQGBmeBDAECATBaMCoG CCsGAQUFBwIBFh5odHRwczovL3d3dy5yYXBpZHNzbC5jb20vbGVnYWwwLAYIKwYB BQUHAgIwIAweaHR0cHM6Ly93d3cucmFwaWRzc2wuY29tL2xlZ2FsMB8GA1UdIwQY MBaAFJfCJ1CewsnsDIgyyHyt4qYBT9pvMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE FjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwVwYIKwYBBQUHAQEESzBJMB8GCCsGAQUF BzABhhNodHRwOi8vZ3Auc3ltY2QuY29tMCYGCCsGAQUFBzAChhpodHRwOi8vZ3Au c3ltY2IuY29tL2dwLmNydDATBgorBgEEAdZ5AgQDAQH/BAIFADANBgkqhkiG9w0B AQsFAAOCAQEApuZ9VVqYOlIrOZ5GFFafwRISq8FGPHiqAwKEMw/b7MjCrDfbMiVM IfHEaA5FhmijdAbr9LRwyU1XVCfy+Q3pKA95kuronFdIbbc8qyr11hBtiYaHURjc /8P5Dco6IRdaMViQcy3gIOgFch7Zk+0Gjp71j8RCRiXvcqIHmrLaEkzGAuMMqERX yp/cofpI+8UfwEEKNIYexZbXRtzuoOWlnm5q32rTFTy8v8QiRI9j52lWGqhlu5ng KXBEa9En9NHlWAOg1yvhuaULM5tsoPu+/fQTlBit/BPvCmrPmURI1DnNnHLZTfvC 1PhGFNLKImuClH8gASNZe8RzU8jnO6UpvQ== -END CERTIFICATE- ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
