RE: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots
Hi Nick We attached an updated version of the affected certificate overview to the bug on February 10, which does contain the date of order and date of issuance. Thanks Arvid > -Original Message- > From: dev-security-policy On > Behalf Of Nick Lamb via dev-security-policy > Sent: donderdag 11 februari 2021 19:12 > To: dev-security-policy@lists.mozilla.org > Cc: Ben Wilson > Subject: Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, > E46, R45 and E45 Roots > > On Tue, 9 Feb 2021 14:29:15 -0700 > Ben Wilson via dev-security-policy > wrote: > > > All, > > GlobalSign has provided a very detailed incident report in Bugzilla - > > see https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2. > > There are a few remaining questions that still need to be answered, so > > this email is just to keep you aware. > > Hopefully later this week I'll be able to come back and see if people > > are satisfied and whether we can proceed with the root inclusion > > request. > > I have a question (if I should write it in Bugzilla instead please say so it is unclear > to me what the correct protocol is) > > GlobalSign have provided a list of 112 other certificates which were issued for the > same reason, I examined some of them manually and determined that they are in > appearance unextraordinary (2048-bit RSA keys for example) and so it's > unsurprising we didn't notice they were issued previously. > > However, the list does not tell me when these certificates were ordered or, if > substantially different, when the email used to "validate" these orders was sent. > > As a result it's hard to be sure whether these certificates were issued perhaps > only a few weeks after they were ordered, which is a relatively minor oversight, > or, like the incident certificate, many years afterwards. I'd like maybe a column of > "order date" and "email sent date" if the two can be different. > > - > > I also have noticed something that definitely isn't (just) for GlobalSign. It seems to > me that the current Ten Blessed Methods do not tell issuers to prevent robots > from "clicking" email links. We don't need a CAPTCHA, just a "Yes I want this > certificate" POST form ought to be enough to defuse typical "anti-virus", "anti- > malware" or automated crawling/ cache building robots. Maybe I just missed > where the BRs tell you to prevent that, and hopefully even without prompting all > issuers using the email-based Blessed Methods have prevented this, > > > Nick. > ___ > 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
Notice on SC31 and CAs using EJBCA
During gap analysis and impact assessment of the changes to the BR in the context of SC31 - Browser Alignment, we noted that our legacy platform, using EJBCA as issuance backend, did not fully support the changes related to not including the "Unspecified" reason code in OCSP responses for the certificates that are revoked with that reason. Refer to BR 1.7.1 section 7.3 and 7.2.2, this specific requirement is effective as of September 30 2020. We raised the issue with PrimeKey and EJBCA version 7.4.2 was released on September 14 2020. This message is intended to inform other CA using EJBCA software and subject to BR of the above. 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: Verifying Auditor Qualifications
ACAB'c is a group of a few eIDAS CABs working together for reasons, they do not represent all eIDAS CABs neither do they have any recognized or official function within the eIDAS ecosystem. Can the ACAB'c member list be relied upon as being accurate and providing correct and latest information on the accreditation status of member CABs? It’s a manual list maintained based on membership applications and their acceptance. Isn't the only current accurate source of accredited eIDAS CAB the 20+ governmental NABs of participating EU countries that are designated to accredit and supervise eIDAS CAB? Without any visible added value or clear and transparent insights on what supervisory function they perform within the context of the WebPKI ecosystem (filtering which eIDAS CAB and reports are acceptable/qualitiative?), why would a specific subset of eIDAS CAB be promoted over other eIDAS CAB? Parties that are interested in becoming a WebPKI CA or maintaining that status often go look at root program requirements as a first source to understand what needs to be done, including what audit attestations that need to be obtained and which parties can provide these. I have difficulties understanding what current reason there is to refer to the ACAB'c and why the "simplified check" seems to suggest only ACAB'c member audit reports are accepted. > -Original Message- > From: dev-security-policy On > Behalf Of Nicholas Knight via dev-security-policy > Sent: maandag 13 juli 2020 15:31 > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Verifying Auditor Qualifications > > It seems exceptionally strange to me that what, from all appearances, is a 4 > year > old advocacy body for auditors could be considered an authoritative source. > ACAB’c does not seem to have done anything at all to acquire the extremely > high > level of credibility such a source needs. > > The idea that an association of auditors can’t keep its website and charter > up to > date does nothing to dispel doubt, and is in fact evidence that ACAB’c is not > capable of its claimed functions. > > I see no browsers or anyone else can rely on ACAB’c, or should. It was not > formed > for that purpose and there is no evidence it even understands that purpose. I > suggest that if they intend to perform this function, it is necessary to > start over > with a new organization with a new charter and new leadership. > ___ > 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: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
GlobalSign recognizes the reported security issue and associated risk, and is working on a plan to remediate the impacted CA hierarchies with first priority on terminating those branches that include issuing CA with private keys outside of GlobalSign's realm. We will soon share an initial plan on our Bugzilla ticket https://bugzilla.mozilla.org/show_bug.cgi?id=1649937. One question we have for the root store operators specifically is what type of assurance they are looking for on the key destruction activities. In the past we've both done key destruction ceremonies without and with (e.g. in the case of addressing a compliance issue like https://bugzilla.mozilla.org/show_bug.cgi?id=1591005) an external auditor witnessing the destruction and issuing an independent ISAE3000 witnessing report. > -Original Message- > From: dev-security-policy On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: woensdag 1 juli 2020 23:06 > To: mozilla-dev-security-policy > Subject: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous > Delegated Responder Cert > > I've created a new batch of certificates that violate 4.9.9 of the BRs, which was > introduced with the first version of the Baseline Requirements as a MUST. This is > https://misissued.com/batch/138/ > > A quick inspection among the affected CAs include O fields of: QuoVadis, > GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus, Actalis, > Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC. > > Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST > include an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP > Delegated Responder within Section 4.2.2.2 as indicated by the presence of the > id-kp-OCSPSigning as an EKU. > > These certificates lack the necessary extension, and as such, violate the BRs. As > the vast majority of these were issued on-or-after 2013-02-01, the Effective Date > of Mozilla Root CA Policy v2.1, these are misissued. You could also consider the > effective date as 2013-05-15, described later in [1] , without changing the results. > > This batch is NOT comprehensive. According to crt.sh, there are approximately > 293 certificates that meet the criteria of "issued by a Mozilla-trusted, TLS-capable > CA, with the OCSPSigning EKU, and without pkix-nocheck". misissued.com had > some issues with parsing some of these certificates, due to other non- > conformities, so I only included a sample. > > Censys.io is aware of approximately 276 certificates that meet this criteria, as you > can see at [2]. The differences in perspectives underscores the importance of > CAs needing to carefully examine the certificates they've issued to understand. > > It's important for CAs to understand this is Security Relevant. While they should > proceed with revoking these CAs within seven (7) days, as defined under the > Baseline Requirements Section 4.9.1.2, the degree of this issue likely also > justifies requiring witnessed Key Destruction Reports, in order to preserve the > integrity of the issuer of these certificates (which may include the CA's root). > > The reason for this is simple: In every case I examined, these are certificates that > appear to nominally be intended as Issuing CAs, not as OCSP Responder > Certificates. It would appear that many CAs were unfamiliar with RFC 6960 when > constructing their certificate profiles, and similarly ignored discussion of this issue > in the past [3], which highlighted the security impact of this. I've flagged this as a > SECURITY matter for CAs to carefully review, because in the cases where a > third-party, other than the Issuing CA, operates such a certificate, the Issuing CA > has delegated the ability to mint arbitrary OCSP responses to this third-party! > > For example, consider a certificate like https://crt.sh/?id=2657658699 . > This certificate, from HARICA, meets Mozilla's definition of "Technically > Constrained" for TLS, in that it lacks the id-kp-serverAuth EKU. However, > because it includes the OCSP Signing EKU, this certificate can be used to sign > arbitrary OCSP messages for HARICA's Root! > > This also applies to non-technically-constrained sub-CAs. For example, consider > this certificate https://crt.sh/?id=21606064 . It was issued by DigiCert to > Microsoft, granting Microsoft the ability to provide OCSP responses for any > certificate issued by Digicert's Baltimore CyberTrust Root. We know from > DigiCert's disclosures that this is independently operated by Microsoft. > > Unfortunately, revocation of this certificate is simply not enough to protect Mozilla > TLS users. This is because this Sub-CA COULD provide OCSP for itself that > would successfully validate, AND provide OCSP for other revoked sub-CAs, even > if it was revoked. That is, if this Sub-CA's key was maliciously used to sign a > GOOD response for itself, it would be accepted. > These security concerns are discussed in Section 4.2.2.2.1 of RFC
RE: Verifying Auditor Qualifications
Hi Kathleen Related to the below it would be helpful if the WebTrust organization would disclose additional details on the licensed WebTrust practitioners: right now there is no data publicly available on historical WebTrust auditor licensing. We don't know as of when an auditor has been licensed and as far as I am aware there is no overview of auditors that did not renew, withdrew or had their license revoked. Having such a list would certainly help CAs in the auditor selection process and better monitoring of auditor qualifications. The Dutch NAB has an excellent inventory of their suspensions and withdrawals of accreditations: https://www.rva.nl/en/accredited-organisations/suspended-withdrawals. We think everyone would benefit from the WebTrust task force / CPA Canada maintaining a similar public inventory. Thanks Arvid > -Original Message- > From: dev-security-policy On > Behalf Of Kathleen Wilson via dev-security-policy > Sent: donderdag 4 juni 2020 1:21 > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Verifying Auditor Qualifications > > All, > > It recently came to my attention that I need to be more diligent in verifying > auditor > qualifications. Therefore, we have added a field in the CCADB called “Date > Qualifications Verified” (on Auditor Location objects), which will be used to > remind > root store operators to check each auditor’s qualifications every year. This > field > can only be edited by a root store operator, and we will enter this date > whenever > we confirm that the auditor is still qualified to perform ETSI or WebTrust > audits. > > Some of you may notice that your Audit Case or Root Inclusion Case has the > message: “Auditor Verification Date is blank”. This warning message is > intended > to remind root store operators that we need to verify the auditor's > qualifications. In > the future you may also notice a warning message when the date in that field > is > over a year old, reminding us root store operators to re-verify the auditor's > qualifications. > > I will greatly appreciate your input on the following new wiki page section, > especially in regards to verifying auditor qualifications. > > https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications > > Thanks, > Kathleen > ___ > 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: GlobalSign: Failure to revoke certificate with compromised private key within 24 hours
An incident report was created for this yesterday: https://bugzilla.mozilla.org/show_bug.cgi?id=1620922 > -Original Message- > From: dev-security-policy On > Behalf Of Matt Palmer via dev-security-policy > Sent: dinsdag 10 maart 2020 1:41 > To: dev-security-policy@lists.mozilla.org > Subject: GlobalSign: Failure to revoke certificate with compromised private key > within 24 hours > > A certificate with a publicly-disclosed private key was reported to GlobalSign for > revocation within the BR-mandated 24 hour period, however the revocation took > place over 46 hours after the report was sent. Several requests for information I > had already provided were made by GlobalSign, however the revocation eventually > took place without any further information being required. Communication from > GlobalSign then appeared to suggest that the certificate had "already" been > revoked, despite timestamps in the CRL indicating otherwise. > > I believe an incident report for this event is warranted, given that GlobalSign was > provided with sufficient information to revoke the certificate in the initial problem > report (based on the fact that revocation eventually took place with no further > information being provided by myself), but failed to do so within the BR-mandated > time period. > > Excuciatingly detailed timeline follows. > > 2020-03-06 21:48:53Z E-mail sent to report-ab...@globalsign.com: > > -8<- > Date: Sat, 7 Mar 2020 08:48:53 +1100 > From: Matt Palmer > To: report-ab...@globalsign.com > Subject: Problem Report for certificate(s) with compromised private key > > One or more certificates issued by your CA are using a private key which has been > publicly disclosed. The list of affected certificates can be retrieved from > > https://crt.sh/?spkisha256=6a02703a7a2ba3f368a2915305383549cf8ada826242269 > 7d62d5ba410e4d93f > > Included below is a CSR, signed by the compromised private key, demonstrating > proof of possession: > > -BEGIN CERTIFICATE REQUEST- > MIIE0TCCArkCAQAwgYsxaTBnBgNVBAMMYFRoZSBrZXkgdGhhdCBzaWduZWQg > dGhp > cyBDU1IgaGFzIGJlZW4gcHVibGljbHkgZGlzY2xvc2VkLiBJdCBzaG91bGQgbm90 > IGJlIHVzZWQgZm9yIGFueSBwdXJwb3NlLjEeMBwGA1UECgwVaHR0cHM6Ly9wd2 > 5l > ZGtleXMuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2OMM6yti > 3q+GhnZsMPYrACVrZWYqn2yz2fH5J6kPONDvHm3P4UgPJb5j0OFUbmng3e41Fw > Wf > QhD7UFbiEtH/fCJLnxuhAlCBZkVTwIBIwIYRpBmSp/shtNBJZvHBPgktF78qQBr5 > HaX9jZOl/z0rLVw42wnzHlMyyeJNCQzBgRqA+Lcgig/9I2qxQvm3C53868i0EE3k > B418D63cEhz6hldoxELt7twoYulwyLk/PXWj/I0qHQZGT1weLD6UXINuxhmcFUDj > 4i5V9UqNWhP4LT/QWjNtqE5y1OOT5qtkczjmSd3TS3GCik3o7v2M7JxwME1T/e/z > unTqhCarZF3HkrN5MxDB/28HsPaSRUpbxzmIUt+GApuVjNWnRW0awlzp8i5wQnmo > x7nNtSSht44DhlWETpPeT3n27LKM64no97aN0NS0LEKc5sFuOcS5sCj5FvsxNm/8 > RhqfQkHXjkhZByTPhYvkQZTTA8Gxsh52Pnr0aTKrNz/fNpcJWzlKvbSmQn7i1Nmn > z6f9cTB3gW9+DjgSq/XjgVZJdGAWD9k5/i+v8b0zSbpprGNh2gkn39QYmWLlS2eu > XhtAhdWAroEBxm5pLA3T50KWcfM1IHsZSHIeneIcR3anUhqnA1vMjZdFdFkX+TCE > n/c6cotq/fESE+ieMdc7NjpTn4w2a+10xHECAwEAAaAAMA0GCSqGSIb3DQEBCw > UA > A4ICAQCnPqJFlaTaNTz0ldS+PepRa8cpf4DXJ/shKBf8ChJ7ivY8+Q6qQWLU4WTM > DSChT+5K2Zlr5LRoIBeTsgyl3345agsPI8BKjw1OpRlxgVsMKlKOd6nCSJPw2NDl > +Ud+s/LbnZJsIn9nb4fQdF+mC4L6Q1GikCkTfQ1SD8RykVgwojiQFwsdaNRy1U2z > uw3QtlYXZ1s/zdgEITBB4x5js1r8+njue3X4hbgmTrnppEpxeaiuKIImLxFCOveo > pv6evi9g8mYCZ2hqvLO2RTO3iTSvbDAgbImr6D0Asem1qdCdNPbhiGXj/kxJNNUQ > P5hb1KmbcdCLIjvMz0+Z6TkIW0q4MowUpUeKx8Y18Pjt9D+nLN9sRLi8vfjvlnt4 > eLENX2156CWMmJQg4n16UjYKaf6dSCvWJYC2TzYJzs+ZEKU71LCkUl/hdj7ZNLtZ > o3Z3C892nPZ56LdJES2wBMFgfMV5EWo4MrriFO7yhpkVp3NlOWkWVjIuTPDsm0g > K > fLVgHQPfgpVR6LT/e2HWISdiogUrACsVFrb5vfehXY2PAewPghkD5Cn3LG6hnXYn > hmjgXDwz2dK5ud3ABJT1UxJtn82o3z3okUDISdeioxw43HBhCQ84p3G+JoRq9x6+ > 2ncweNmCQQ66tsX386ywKpPQJ4/1DrRsOKdSSy7siwwtR437Rg== > -END CERTIFICATE REQUEST- > > Please revoke all affected certificates within 24 hours, as per the Baseline > Requirements. > > - Matt > ->8- > > 2020-03-06 21:49:04Z E-mail is accepted for delivery by a GlobalSign MX: > > -8<- > Mar 6 21:49:04 minotaur postfix/smtp[26026]: 75BC71857EE: > to=, > relay=globalsign-com.mail.protection.outlook.com[104.47.93.36]:25, > delay=6.8, delays=0.47/0.01/0.9/5.4, dsn=2.6.0, status=sent (250 2.6.0 > <20200306214853.kpohtnh5y2m3k...@hezmatt.org> [InternalId=34857954577034, > Hostname=HK0PR03MB2755.apcprd03.prod.outlook.com] 10967 bytes in 3.479, > 3.078 KB/sec Queued mail for delivery) > ->8- > > 2020-03-06 21:49:15Z Auto-ack e-mail received from GlobalSign: > > -8<- > Dear Matt Palmer, > > Thank you for reporting this issue to GlobalSign. Case #04076325: "Problem > Report for certificate(s) with compromised private key" has been created and a > GlobalSign representative will investigate this immediately. If requested you will > receive a response from a designated representative as soon as possible. > > Thank you, > Customer Service Team GlobalSign > ->8- > > 2020-03-06 22:08:06Z Human response from GlobalSign: >
RE: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic
When I initially raised the topic I had two things in mind: -What if a facility can’t be audited? -If main key management facilities are down can WebPKI CA meet SSLBR 4.9.1.2? As for the inability to audit, a few things come to mind based on the previous shared thoughts: -Inform root programs ASAP if a certain location is in a situation where it cannot be inspected within the three months after the period under audit -File an “exception request” (which requires to be renew regularly to ensure CAs need to continuously justify an incomplete audit) -Complete the audit for all locations that can be audited -Deliver updated report that incorporates the facilities as soon as the facility is back available for inspection Ryan, related to your thought “Similarly, if a CA’s preferred auditors are from a region affected by travel restrictions, but other accredited auditors exist that would be capable, would that be sufficient?” -Auditors are not that flexible on reporting formats and doing a specific subset of a standards on a specific location. -What would the root programs accept in terms of such an ad-hoc report as it will not be an ISAE3000/CSAE3000/SSAE18 format? -Depending on the CA it would also be multiple reports that will be incomplete: WebTrust, SSLBR, EV, (EV) Code Signing -Which controls / criteria should be reported on? Only the ones related to physical security? For the key material security and key management continuity aspect, compared to the controls I would think a typical CA would implement the WebTrust standard is quite brief and vague: -Criterion #3.8 focuses on general CA continuity and availability of technology and information. For key material it focuses on having back-ups. -There is one specific control (#3.8.6) that talks a bit about securing a facility during a disaster None of these controls really talk focused about the importance of or set any timings for having a capability available at original or remote site to perform critical key management activities such as timely ICA revocation. Also generally our opinion is that key material protection requirements in WT are substandard to the level of protection that is required for WebPKI CAs. Based on our internal risk appetite we have implemented additional controls, including but not limited to: -Having key management facilities / capability on different continents in politically stable countries -Having additional locations on top of the above facilities under different political rule to which we can move key material quickly and securely in case of any threat or instability -“Key management facility” means a facility where key material is stored. Credentials to unlock the key management facility and key material are stored in at least two other different locations in close proximity to the key management facility and require the presence of different roles to obtain access. -Rotational key management activities in the different locations to make sure the facilities are and stay operational and plans work when it comes to a BCP execution -A colluded group of at least six trusted role people is required in order to obtain access to key management material From: Ryan Sleevi Sent: vrijdag 28 februari 2020 19:32 To: Ryan Sleevi Cc: mozilla-dev-security-policy ; Arvid Vermote Subject: Re: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic Hi Arvid, I wanted to follow-up, and see if you had suggestions or ideas here for appropriate next steps. Understandably, as more countries are affected, this will no doubt continue to be an issue. I think you're spot on for asking early, as you did, and I'm hoping GlobalSign (and others!) might have ideas on appropriate risk mitigation and potential remediation strategies. 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
Auditing of CA facilities in lockdown because of an environmental disaster/pandemic
COVID-19 is going on and there currently is a quarantine of certain areas in China and also alert levels are further raising in other (mainly East-Asian) countries. How will the root programs approach CA facilities with key material that are in a lockdown or in a territory that is not accessible by auditors and hence cannot be inspected within the three months after the end of the CA's period-under-audit? Lockdown in the above meaning properly secured according to the requirements and BCP/DR plans but because of external conditions not accessible and available for external auditors / inspection. 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: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements
GlobalSign has revoked the respective certificates and is investigating root cause. Thanks. > -Original Message- > From: dev-security-policy On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: dinsdag 21 mei 2019 6:06 > To: Brian Smith > Cc: Ryan Sleevi ; mozilla-dev-security-policy security-pol...@lists.mozilla.org>; Wayne Thayer > Subject: Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash > Requirements > > On Thu, May 9, 2019 at 4:48 PM Brian Smith wrote: > > > On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer wrote: > > > >> On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi wrote: > >> > >>> Thank you David and Ryan! This appears to me to be a reasonable > >>> improvement to our policy. > >>> > >> > >> Brian: could I ask you to review the proposed change? > >> > >> > >>> This does not, however, address the last part of what Brian proposes > >>> - which is examining if, how many, and which CAs would fail to meet > >>> these encoding requirements today, either in their roots, > >>> subordinates, or leaf certificates. > >>> > >>> > >> While I agree that this would be useful information, for the purpose > >> of moving ahead with this policy change would it instead be > >> reasonable to set an effective date and require certificates issued > >> (notBefore) after that date to comply, putting the burden on CAs to > >> verify their implementations rather than relying on someone else to do that > work? > >> > > > > My understanding here is that the proposed text is not imposing a new > > requirement, but more explicitly stating a requirement that is already > > imposed by the BRs. AFAICT BRs require syntactically valid X.509 > > certificates, RFC 5280 defines what's syntactically valid, RFC 5280 > > defers to other documents about what is allowed for each algorithm > > identifier, and this is an attempt to collect all those requirements > > into one spot for convenience. > > > > I unintentionally let this drop off my radar. > > I did some light analysis, based on analyzing simply the bytes of the cert (i.e. > without structural parsing), simply looking at whether or not one of the prescribed > sequences appears, first for SPKIs, then for signatures. > > For SPKIs, I only found a total of 9 unexpired certs, so I've just reproduced them > here: > - > https://crt.sh/?c=ad567be233e98ac621e8b760005f37f1d7e916d73c602391771ab5f2 > 3f7af38b > - > https://crt.sh/?c=b719593d1e625e45f42ab3d1537e0a9c7a33c0a87244e7000db6157 > 1bc0fd98b > - > https://crt.sh/?c=541e29ce0aee8244a43b31e031208e6808a7e412d6c9cda6cd032d5 > 28ea0c690 > - > https://crt.sh/?c=6101a94793441c3b85ac653703d62d5c65ca6457662b36ad7abd3ee > 43d5eec11 > - > https://crt.sh/?c=ca304b895d0d652da1c352dbda577f7c70c5f6741758e17a919a97d > 063ad56c7 > - > https://crt.sh/?c=91d876790b645196389d3c92a6b480969557192ecdd2bfeaaced6c0 > 7948d9d5c > - > https://crt.sh/?c=96185e2fadc17a5b896338a3fcce3647b3b2f9221c61c9624814c4d3 > 7b884dbb > - > https://crt.sh/?c=9a9ec285f834b421416e5e5ba45727deaf92adf37e76a82cdf6d45d0 > fba0728c > - (Revoked) > https://crt.sh/?c=5cf9ff16c5d1e128a2082df9d290d1571c1a8f2f782bc1cacd2b0437 > 094f0e13 > > Of the 8 unrevoked, they're all issued by a single CA - GlobalSign - and are all > RSA keys that lack the explicit NULL parameter, and thus violate the requirements > of https://tools.ietf.org/html/rfc3279#section-2.3.1 > > These are flagged by cablint (but not zlint), so that is an opportunity for CAs to > improve things - both in how they encode and how they lint. > > I haven't (yet) gone through the Signature encodings, but that should hopefully > address the SPKI concerns. Of course, I may have botched things rather > significantly in my queries, but at least sharing my data provides a way for people > to prove that :) > > > > > > It would be easier to understand if this is true if the proposed text > > cited the RFCs, like RFC 4055, that actually impose the requirements > > that result in the given encodings. > > > > Could you clarify, do you just mean adding references to each of the example > encodings (such as the above example, for the SPKI encoding)? > ___ > 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: SSL private key for *.alipcsec.com embedded in PC client executables
Based on the information reported in this thread GlobalSign has started the
necessary activities to investigate this potential misuse.
Arvid
On Tuesday, December 11, 2018 at 8:24:43 AM UTC+1, Mark Steward wrote:
> This time it's just hanging around in memory, no need to do anything
> about the anti-debug.
>
> $ openssl x509 -noout -modulus -in 300288180.crt|md5sum
> f423a009387fb7a306673b517ed4f163 -
> $ openssl rsa -noout -modulus -in alibaba-localhost.key.pem|md5sum
> f423a009387fb7a306673b517ed4f163 -
>
> You can verify that I've signed lorem ipsum with the following:
>
> $ wget https://crt.sh/?d=300288180 -O 300288180.crt
> $ wget https://rack.ms/b/UsNQv74sfH40/msg.txt{,.sig-sha256.b64}
> $ openssl dgst -sha256 -verify <(openssl x509 -in 300288180.crt
> -pubkey -noout) -signature <(base64 -d msg.txt.sig-sha256.b64) msg.txt
>
> As the domain name suggests, this is part of the
> AlibabaProtect/"Alibaba PC Safe Service" that comes bundled with the
> Youku client.
>
>
> Mark
>
>
> Mark
> On Tue, Dec 11, 2018 at 5:37 AM Xiaoyin Liu via dev-security-policy
> wrote:
> >
> > Hello,
> >
> > I think I found a SSL certificate misuse issue, but I am not sure if this
> > is indeed a misuse, so I want to ask about it on this list.
> >
> > Here is the issue: After I installed Youku Windows client
> > (https://pd.youku.com/pc, installer:
> > https://pcclient.download.youku.com/youkuclient/youkuclient_setup_7.6.7.11220.exe),
> > it starts a local HTTPS server, listening on localhost:6691. Output of
> > “openssl s_client -connect 127.0.0.1:6691” indicates that this local server
> > uses a valid SSL certificate, issued to "Alibaba (China) Technology Co.,
> > Ltd.” CN=*.alipcsec.com, and issued by GlobalSign. It’s a publicly trusted
> > OV cert, and is valid until Jan 13, 2019. Later, I found that
> > local.alipcsec.com resolves to 127.0.0.1, and
> > https://local.alipcsec.com:6691/ is used for inter-process communication.
> >
> > It’s clear that the private key for *.alipcsec.com is embedded in the
> > executable, but all the executables that may embed the private key are
> > packed by VMProtect, and the process has anti-debugging protection. I tried
> > plenty of methods to extract the private key, but didn’t succeed. I
> > reported this to Alibaba SRC anyway. They replied that they ignore this
> > issue unless I can successfully extract the key.
> >
> > So is this a certificate misuse issue, even if the private key is
> > obfuscated? If so, do I have to extract the private key first before the CA
> > can revoke the cert?
> >
> > Thank you!
> >
> > Best,
> > Xiaoyin Liu
> >
> > Here is the certificate:
> > -BEGIN CERTIFICATE-
> > MIIHTjCCBjagAwIBAgIMCpI/GtuuSFspBu4EMA0GCSqGSIb3DQEBCwUAMGYxCzAJ
> > BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTwwOgYDVQQDEzNH
> > bG9iYWxTaWduIE9yZ2FuaXphdGlvbiBWYWxpZGF0aW9uIENBIC0gU0hBMjU2IC0g
> > RzIwHhcNMTgwMTEyMDgxMTA1WhcNMTkwMTEzMDgxMTA1WjB7MQswCQYDVQQGEwJD
> > TjERMA8GA1UECBMIWmhlSmlhbmcxETAPBgNVBAcTCEhhbmdaaG91MS0wKwYDVQQK
> > EyRBbGliYWJhIChDaGluYSkgVGVjaG5vbG9neSBDby4sIEx0ZC4xFzAVBgNVBAMM
> > DiouYWxpcGNzZWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
> > 9PJcPzpUNRJeA8+YF8cRZEn75q+fSsWWkm6JfIlOKorYXwYJB80de4+Bia3AgzfO
> > wqwWfPGrRYh5OY4ujjsKF5XkWG22SLlzi5xB9zAeVKHYTo2U6aKrKnht9XyYvnZX
> > ocIuaSxkqq4rQ9UwiEYB6lvy8RY1orYu33HtrGD5W3w9SWf2AwB0rCNp0BeSRaGB
> > JEEXzgVECbL+deJZgZflae1gQ9q4PftDHuGXLNe8PLYq2D4+oKbYvbYtI9WKIMuh
> > 1dL70QBbcW0y4jFr2/337H8/KhBaCb3ZBZQI4LUnYL8RVeAVJFpX/PuiHMh9uNTm
> > oW1if7XQswJCWx3td5tWiwIDAQABo4ID5TCCA+EwDgYDVR0PAQH/BAQDAgWgMIGg
> > BggrBgEFBQcBAQSBkzCBkDBNBggrBgEFBQcwAoZBaHR0cDovL3NlY3VyZS5nbG9i
> > YWxzaWduLmNvbS9jYWNlcnQvZ3Nvcmdhbml6YXRpb252YWxzaGEyZzJyMS5jcnQw
> > PwYIKwYBBQUHMAGGM2h0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9nc29yZ2Fu
> > aXphdGlvbnZhbHNoYTJnMjBWBgNVHSAETzBNMEEGCSsGAQQBoDIBFDA0MDIGCCsG
> > AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAI
> > BgZngQwBAgIwCQYDVR0TBAIwADBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vY3Js
> > Lmdsb2JhbHNpZ24uY29tL2dzL2dzb3JnYW5pemF0aW9udmFsc2hhMmcyLmNybDAn
> > BgNVHREEIDAegg4qLmFsaXBjc2VjLmNvbYIMYWxpcGNzZWMuY29tMB0GA1UdJQQW
> > MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUoIFBQJomlUEiLibD+luC
> > PKGhbykwHwYDVR0jBBgwFoAUlt5h8b0cFilTHMDMfTuDAEDmGnwwggH0BgorBgEE
> > AdZ5AgQCBIIB5ASCAeAB3gB2AN3rHSt6DU+mIIuBrYFocH4ujp0B1VyIjT0RxM22
> > 7L7MAAABYOlsKGEAAAQDAEcwRQIhANem+QHeaxpf7wmjtQe6rdbf5o/JKiM6aVgy
> > 0gnJk/UTAiBNZ0newmCtHi/f1uzmmzWNeVIl4apUko2yChwTUJObMAB1AKS5CZC0
> > GFgUh7sTosxncAo8NZgE+RvfuON3zQ7IDdwQAAABYOlsJ/wAAAQDAEYwRAIgUAxl
> > oaOwXSSPUdDmix7rwcaD2/QAiQcj0Iij14ZB5dMCIG0hAMD7iukwI28DIgy+StxR
> > 2B1LB1PLyMGa1ByTxyx6AHUAVhQGmi/XwuzT9eG9RLI+x0Z2ubyZEVzA75SYVdaJ
> > 0N0AAAFg6WwodQAABAMARjBEAiB5dRrIvSx5euaya6RItzL6bbRt4QtLj3XbrU5d
> > hpLOqgIgTTN315YeiNg+dYmtCCCU1OG56IhScJsP0Kac+JmrI98AdgDuS723dc5g
> > uuFCaR+r4Z5mow9+X7By2IMAxHuJeqj9ywAAAWDpbCrrAAAEAwBHMEUCIAvmesN/
> > F1V57QuX69pubfx7pW2tCJRHREznZOZbEniVAiEA37SmlQQYZhAUFJ02dE5SfNlE
> >
