localhost.megasyncloopback.mega.nz private key in client

[summe...@gmail.com]

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-----

[Ben Wilson]

Thank you Norbert. We will look into this. I'm cc'ing rev...@digicert.com
to follow up.

-----Original Message-----
From: dev-security-policy
<dev-security-policy-bounces+ben=digice...@lists.mozilla.org> On Behalf
Of summern1538--- via dev-security-policy
Sent: Thursday, August 2, 2018 4:06 AM
To: mozilla-dev-s...@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&u=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&u=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&u=https%3A%2F%2Flocalhost.megasyncloopback.mega.nz%3
A6342%2F`.

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://clicktime.symantec.com/a/1/iuG7YASf30D4XjftMKutJfzMrl2Bk2NdCy3Fl4m3O
YU=?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&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-se
curity-policy

[Ben Wilson]

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

[summe...@gmail.com]

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

[Alex Cohn]

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_...@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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Hanno Böck]

On Sun, 5 Aug 2018 15:23:42 -0500
Alex Cohn via dev-security-policy

<dev-secur...@lists.mozilla.org> 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_...@comodoca.com for followup.

As of today this is still unrevoked:
https://crt.sh/?id=630835231&opt=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

[Alex Cohn]

On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck <ha...@hboeck.de> wrote:

>
> As of today this is still unrevoked:
> https://crt.sh/?id=630835231&opt=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_...@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 "ssla...@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 ssla...@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

[Tim Hollebeek]

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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

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.

> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org

> > https://lists.mozilla.org/listinfo/dev-security-policy

>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>
>

[Jay Wilson]

The certificate has been revoked.
The bounce issue has been escalated to resolve.
Regards,

From: Alex Cohn <al...@alexcohn.com>
Sent: Wednesday, August 08, 2018 5:01 PM
To: ha...@hboeck.de
Cc: summe...@gmail.com; mozilla-dev-s...@lists.mozilla.org; #SSL_ABUSE <ssl_...@comodoca.com>
Subject: Re: localhost.megasyncloopback.mega.nz private key in client

On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck <ha...@hboeck.de<mailto:ha...@hboeck.de>> wrote:

As of today this is still unrevoked:
https://crt.sh/?id=630835231&opt=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_...@comodoca.com<mailto:ssl_...@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 "ssla...@comodo.com<mailto:ssla...@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 ssla...@comodoca.com<mailto:ssla...@comodoca.com> as the "problem reporting" address for the cert in question. I have not tried this address.

[Jay Wilson]

+Adding Robin Alden and Richard Smith

From: Ryan Sleevi <ry...@sleevi.com>
Sent: Thursday, August 09, 2018 8:15 AM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Alex Cohn <al...@alexcohn.com>; ha...@hboeck.de; mozilla-dev-s...@lists.mozilla.org; #SSL_ABUSE <ssl_...@comodoca.com>; summe...@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 <dev-secur...@lists.mozilla.org<mailto:dev-secur...@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-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>> On
> Behalf Of Alex Cohn via dev-security-policy
> Sent: Wednesday, August 8, 2018 4:01 PM

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Wayne Thayer]

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-secur...@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-secur...@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-...@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-s...@lists.mozilla.org;
> > ssl_...@comodoca.com;
> > > summe...@gmail.com
> > > Subject: Re: localhost.megasyncloopback.mega.nz private key in client

> > >
> > > On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck <ha...@hboeck.de> wrote:
> > >
> > > >
> > > > As of today this is still unrevoked:
> > > > https://crt.sh/?id=630835231&opt=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_...@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 "ssla...@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 ssla...@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-secur...@lists.mozilla.org

> > > https://lists.mozilla.org/listinfo/dev-security-policy

> >
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org

> > https://lists.mozilla.org/listinfo/dev-security-policy

> >
> >
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Hanno Böck]

On Thu, 9 Aug 2018 13:24:48 +0000
Jay Wilson via dev-security-policy

<dev-secur...@lists.mozilla.org> 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&opt=ocsp

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Jay Wilson]

+Adding Robin Alden and Richard Smith

[Jay Wilson]

[Tim Hollebeek]

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 <ry...@sleevi.com>
Sent: Thursday, August 9, 2018 7:15 AM
To: Tim Hollebeek <tim.ho...@digicert.com>

Cc: Alex Cohn <al...@alexcohn.com>; ha...@hboeck.de; mozilla-dev-s...@lists.mozilla.org; ssl_...@comodoca.com; summe...@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 <dev-secur...@lists.mozilla.org <mailto:dev-secur...@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-...@lists.mozilla.org <mailto:dev-security-...@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-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org> ; ssl_...@comodoca.com <mailto:ssl_...@comodoca.com> ;
> summe...@gmail.com <mailto:summe...@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 <ha...@hboeck.de <mailto:ha...@hboeck.de> > wrote:
>
> >
> > As of today this is still unrevoked:

> > https://crt.sh/?id=630835231 <https://crt.sh/?id=630835231&opt=ocsp> &opt=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_...@comodoca.com <mailto:ssl_...@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 "ssla...@comodo.com <mailto:ssla...@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 ssla...@comodoca.com <mailto:ssla...@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-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy


_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Tim Hollebeek]

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.

> <dev-secur...@lists.mozilla.org <mailto:dev-security-

> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org

> > <mailto:dev-secur...@lists.mozilla.org>
> > https://lists.mozilla.org/listinfo/dev-security-policy
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org <mailto:dev-security-
> pol...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>

[Hanno Böck]

On Thu, 9 Aug 2018 13:24:48 +0000
Jay Wilson via dev-security-policy
<dev-secur...@lists.mozilla.org> 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&opt=ocsp

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Robin Alden]

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 <ha...@hboeck.de>

> Sent: 08 August 2018 15:18
> Cc: Alex Cohn <al...@alexcohn.com>; summe...@gmail.com; mozilla-
> dev-secur...@lists.mozilla.org; #SSL_ABUSE
> <ssl_...@comodoca.com>
> 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

> <dev-secur...@lists.mozilla.org> 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_...@comodoca.com for followup.
>

> As of today this is still unrevoked:

> https://crt.sh/?id=630835231&opt=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.
>