Re: Microsoft to remove WoSign and StartCom certificates in Windows 10
This blog post is very vague, one can understood from it that Microsoft will not trust any new certificates from these two CAs: "Microsoft will begin the natural deprecation of WoSign and StartCom certificates by setting a “NotBefore” date ... Windows 10 will not trust any new certificates from these CAs after September 2017." But this probably not the case; I guess the article refer to removal of the old roots of StartCom and WoSign as they [probably] didn't go through Microsoft Audit process again (required annually) for these certs [1]. 'Microsoft Trusted Root Certificate' [2] isn't open to public comments/review, so we can't really tell what exactly is that status, probably StartCom and WoSign will file a request for the new roots to be included. Links: 1. http://aka.ms/auditreqs 2. https://technet.microsoft.com/en-us/library/cc751157.aspx ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom cross-signs disclosed by Certinomis
On Monday, August 7, 2017 at 11:03:27 PM UTC+3, Jakob Bohm wrote: > 7. At Quihoo: Actually get rid of Richard Wang, not just change his >title from CEO to COO. I didn't map the new hierarchy of the "Spanish" StartCom CA ("StartCom CA Spain Sociedad Limitada"), having trouble registering to the Spanish company house and pull documents (I pulled from 3rd party, but they're garbage [1] [2]). I did mange to see that Mr. Barreira is the Directory but nothing on the share holders or parent company. I took a quick look at StartCom UK (as the information there is free) and noticed Mr. Wang became a director again [3]... I wonder who is "StartCom CA Spain Sociedad Limitada" parent/share holder, maybe a disclosure? Links: 1. https://www.letsphish.org/files/StartCom-CA-SPA-Appointment.pdf 2. https://www.letsphish.org/files/StartCom-CA-SPA-Profile.pdf 3. https://beta.companieshouse.gov.uk/company/09744347 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom cross-signs disclosed by Certinomis
Trust is something you *gain*. I want to believe the internet has come a long way from PGP signing parties. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign new system passed Cure 53 system security audit
On Monday, July 10, 2017 at 9:00:04 AM UTC+3, Richard Wang wrote: > " 5. Provide auditor[3] attestation that a full security audit of the CA’s > issuing infrastructure has been successfully completed. " > " [3] The auditor must be an external company, and approved by Mozilla. " What is the source? According to this thread [1]: "1. Provide a list of changes that the CA plans to implement to ensure that there are no future violations of Mozilla Policy and the Baseline Requirements." One of these changes is to remove the person responsible for: 1. Releasing unsecured and not fully tested software that allowed issuing certificates for Github without proper checks. 2. Back-dating SHA1 certificates. 3. Secretly purchasing another CA without disclosing it to Mozilla. 4. Actively lying and misleading about 2 and 3. To my understanding, from reading the "Remediation Plan", one of the requirements made for WoSign by itself/parent company, is to remove the person responsible for most of the issue caused them to lose the trust bit. I'm not in *any* position to tell who shell manage the daily operations of WoSign, but it gives a strong indication that nothing had really changed. Links: 1. https://groups.google.com/d/msg/mozilla.dev.security.policy/BV5XyFJLnQM/_DwiB1PDGQAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign new system passed Cure 53 system security audit
Mr. Wang is mentioned on the end of the document, what is Richard Wang current official responsibility of Mr. Wang at WoSign? According to the incident report, release on October 2016 [1], Mr. Wang was suppose to be relieved of his duties as CEO, this is mentioned in 3 separate paragraphs (P.17,P.25,P.26). Links: 1. https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Update
The next step, if Symantec wish to continue to use their current PKI in the future, should be logging (ASAP) *all* of the certificates they issued to a CT log, then we'll know how deep is the rabbit hole. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list
On Thursday, April 20, 2017 at 4:03:36 PM UTC+3, Gervase Markham wrote: > Mozilla also doesn't believe that it's the job of CAs to police phishing CAs should police as long as the browser gives positive reinforcement to the end-users when they access a [phishing] site. There were suggestions in the past to remove the 'green lock' for DV/OV certificates. Once this is done, I believe CAs that generates those certs can stop "policing". ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
On Tuesday, February 28, 2017 at 6:00:47 PM UTC+2, Nick Lamb wrote: > This is useful independent evidence that (at least some of) the names did > exist at one time. The problem is that they're "re-keying" certificates for domains that are no longer in control of their subscribers (as Andrew Ayer brought up, they're allowed to do that). I reviewed 4 certificates, out of the 38 domains I checked, 1 is alive and using Incapsula+GlobalSign cert (testslsslmay15.com). https://crt.sh/?id=96720534: Validity: - Not Before: Feb 23 16:11:07 2017 GMT - Not After : Aug 1 10:08:40 2017 GMT X509v3 Subject Alternative Name: - DNS:test-ssldomnew.com - DNS:test02dec.com - DNS:testmacsldec2.net - DNS:testmacsldec2.org - DNS:testmltdmnov28.net - DNS:testmltdmslupslnov27.com - DNS:testnov28.com - DNS:testslsslnov26.mobi - DNS:testyu6788.net https://crt.sh/?id=97019485: Validity: - Not Before: Feb 24 16:19:16 2017 GMT - Not After : Jul 18 07:58:51 2017 GMT X509v3 Subject Alternative Name: - DNS:testbetaslsslmay14.info - DNS:testbetaslsslmay14.me - DNS:testbetaslsslmay14.mobi - DNS:testnovemberssl.com - DNS:testslsslmay15.biz - DNS:testslsslmay15.co + DNS:testslsslmay15.com - DNS:testslsslmay15.info - DNS:testssl2may22.com - DNS:testsslonaug12.com https://crt.sh/?id=97260721: Validity: - Not Before: Feb 25 09:39:46 2017 GMT - Not After : Sep 26 06:39:49 2017 GMT X509v3 Subject Alternative Name: - DNS:mar28sitelocktesting.biz - DNS:waftestingforsni.info - DNS:sslonwafdomain.me - DNS:testbetaslsslmay14.co - DNS:testlpssl.com - DNS:testslsslfeb20.org - DNS:testslsslmay15.me https://crt.sh/?id=97257790: Validity: - Not Before: Feb 25 19:32:50 2017 GMT - Not After : Oct 3 13:53:31 2017 GMT X509v3 Subject Alternative Name: - DNS:slsslfeb17.com - DNS:sslonwafdomain.biz - DNS:sslonwafdomain.co - DNS:testdiyaguru20131002b.com - DNS:testdomainforwaf.mobi - DNS:testregrroct6.org - DNS:testslsslapr7.com - DNS:testslsslfeb17.co - DNS:testslsslfeb17.com - DNS:testslsslfeb17.org - DNS:testssllaunchmay23.info - DNS:testssllivemay23.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
On Tuesday, February 28, 2017 at 5:49:32 PM UTC+2, Andrew Ayer wrote: > Note that the BRs do not require a domain to exist when a CA issues a > DV/OV certificate for it. The BRs only require that the CA validated > the domain at some point in the 39 months prior to issuance. Sad to know. Pasting the ballot for future reference: --- 3.2.2.4. Validation of Domain Authorization or Control The CA SHALL confirm that, as of the date the Certificate issues, either the CA or a Delegated Third Party has validated each Fully‐Qualified Domain Name (FQDN) listed in the Certificate using at least one of the methods listed below. Completed confirmations of Applicant authority may be valid for the issuance of multiple certificates over time. In all cases, the confirmation must have been initiated within the time period specified in the relevant requirement (such as Section 3.3.1 of this document) prior to certificate issuance. For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate. --- 3.3.1. Identification and Authentication for Routine Re‐key Section 6.3.2 limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, provided that the CA obtained the data or document from a source specified under Section 3.2 no more than thirty‐nine (39) months prior to issuing the Certificate. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
On Tuesday, February 28, 2017 at 1:38:25 PM UTC+2, Gervase Markham wrote: > I think that without more evidence we must assume that GlobalSign > validated this domain correctly at a time when it existed. There are many more test*.* domains, non of those (about 10) I checked exist. I will compose a full list and reply. I also would like to have an official reply from GlobalSign saying that "on the date they issue the certificate the domain exists". ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GlobalSign BR violation
How those lines are parsed? what happens when a client reaches a whitespace? Will this allow 'vietnamairlines.com' to use 'owa', 'mail' and 'autodiscover' in their internal infrastructure? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
I talked with Ofer from Incapsula, he said the domain exist at some point; Someone have access to domain tools or other tool to verify this matter? Based on domaintools I can say the domain did exist but I can't tell when it cease to exist. https://research.domaintools.com/research/whois-history/search/?q=testslsslfeb20.me There are several other domains, maybe someone can compose a better list: https://censys.io/certificates?q=parsed.subject.common_name%3A+incapsula.com+and+parsed.extensions.subject_alt_name.dns_names%3A+test*ssl*%28jan%7Cfeb%7Cmar%7Capr%7Cmay%7Cjun%7Cjul%7Caug%7Csep%7Coct%7Cnov%7Cdec%29 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
This practice seem to go back to Apr 2014. Link: https://crt.sh/?dNSName=testslsslfeb20.me ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy