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: Certigna Root Renewal Request
Hello, Based on the updated documentation, I've compiled the following questions for clarification: CPS Section 1.4.2 states "Unless stated otherwise, in this document, “RA” covers the Registration Authority and Delegate Registration Authorities." CPS Section 3.2 calls out DRAs ability to perform initial identity validation steps and uses the phrasing “RA (RA or DRA)” at the beginning of the section. CPS Section 4.2.1 states that during the identification and request validation process, that a DRA forwards the steps undertaken (including validation of domain control), and the RA "ensures that the request corresponds to the mandate of the DRA operator" Due to the language in 1.4.2 stating that unless stated otherwise, “RA” refers to both Registration Authorities and Delegated Registration Authorities, can you direct me to where in the CP/CPS it calls out that DRAs, Certificate Managers, and Certificate Agents (as defined in Section 1.4.5) are specifically unable to perform the validation checks of 3.2.2.4 and 3.2.2.5? Additionally, what does it mean for an RA to “ensure that the request corresponds to the mandate of the DRA operator”? CPS Section 4.2.1: If the request is valid and allows to obtain with accuracy the authorization to issue the certificate by a legal representative of the entity which is owner of the domain names, the CA authorizes itself to issue the certificate even if the CA is not present in the list of authorized CA. This appears to directly contravene BR Section 3.2.2.8, which specifies the following 3 scenarios in which a CA can issue a certificate despite not appearing in the CAA record: • CAA checking is optional for certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked. Forum Guideline Baseline Requirements, v. 1.6.0 21 • CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in Baseline Requirements section 7.1.5, where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant. • CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain's DNS. CPS Section 3.2.7 calls out special actions taken for “High Risk Certification Requests”. It says the procedures for determining high risk as well as additional vetting requirements are documented, however, I do not see this documentation anywhere. On what basis is a certification request deemed “high risk” and in what way, specifically, does this impact a subscriber’s ability to obtain a certificate? Root CA CP Section 4.3.2: The delivery of certificate is achieved during the key ceremony, to a CA administrator authorized by CA and in charge of its exploitation and diffusion. Can you please explain what these sentences mean? This sub-section is cited as the response to BR Section 4.3.1 CA Actions during Certificate Issuance in the latest version of the BR self-assessment, but does not appear to speak to this requirement. ___ 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 b3BiYWNrLm1lZ2EubnowCQYDVR0TBAIwADArBgNVHR8EJDAiMCCgHqAchhpodHRw
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
Re: AC Camerfirma's undisclosed itermediate certificates incident report
On Thu, Aug 02, 2018 at 06:19:42AM -0700, Juan Angel Martin via dev-security-policy wrote: > > 6) Explanation about how and why the mistakes were made or bugs introduced, > and how they avoided detection until now. > > The procedure established to publish the CAs into CCADB wasn't correct cause > it didn’t foresee the contingency of the person in charge of disclosing CA’s > certificates into CCADB and the person acting as a backup weren’t available. This looks like a process issue to me, and adding a 3rd person won't fix that. The certificate should not having been used until someone confirmed that it was done. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
AC Camerfirma's undisclosed itermediate certificates incident report
Hello, 1) How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. We receive a communication via Buzilla from Wayne Thayer (https://bugzilla.mozilla.org/show_bug.cgi?id=1455147) on 2018-07-30 16:31:25 PDT). Wayne, thanks once again. 2) A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. The task about disclose the first CA certificate (https://crt.sh/?sha256=1defd59846cc2049ba1f1a74d3a8329d1357a2d47c1e1b0c15c27a8c60295455=mozilladisclosure) was identified and planned prevouisly and it must be done once the certificate was issued on Jun 29 10:27:17 2018 GMT The second CA certificate (https://crt.sh/?sha256=06a57d1cd5879fba2135610dd8d725cc268d2a6de8a463d424c4b9da89848696=mozilladisclosure) was issued on Jul 3 12:01:18 2018 GMT. We’ve failed to perform the task about disclose the CAs into CCADB. We've disclosed these certificates on July the 31th. 6) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. The procedure established to publish the CAs into CCADB wasn't correct cause it didn’t foresee the contingency of the person in charge of disclosing CA’s certificates into CCADB and the person acting as a backup weren’t available. 7) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. We're adding a third person as a point of contact into CCADB. We've already done the request and the person already has the necessary knowledge to manage this task. Juan Angel ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
