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: 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 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: 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
Re: Incident Report – Certificates issued without proper domain validation
On Wednesday, January 11, 2017 at 5:03:08 AM UTC+2, Wayne Thayer wrote: > ... and will also be logged to the Google Pilot CT log. Why not posting _ALL_ certificates issues via that method to CT log? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On Sunday, November 6, 2016 at 12:11:43 AM UTC+2, Ryan Sleevi wrote: > Can you tell me where that clause indicates that they should use the Alexa > Top 1 million to consider a request "High Risk"? It doesn't, "High risk" is left for the CA's interpretation. But after the fact you can say that they failed to identify a "High risk" request with their current state of their system and they SHOULD be required to update it (to avoid future requests to pass for the specific domain in question), and they MAY need to make their system more robust to identify other "High risk" requests and not just acting after the fact. Alexa top ~1000 is a good indicator for requests that should be considered as "High risk" [1] [2], especially in a free tier service. Links: 1. https://github.com/certbot/certbot/issues/47#issuecomment-64060616 2. https://community.letsencrypt.org/t/name-is-blacklisted-on-renew/9012/19 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Cerificate Concern about Cloudflare's DNS
On Friday, November 4, 2016 at 12:18:40 PM UTC+2, Gervase Markham wrote: > ... But because WoSign had done the appropriate domain control checks, > we did not consider this a mistake by WoSign. (to my understanding) They did violate a "SHALL" guideline: "The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements." I don't recall if they automatically approved or manually approved it by mistake (the operator wasn't familiar with Alibaba). alicdn.com is ranked 760 in Alexa top 1 million, and requests for this domain should be considered "high risk": CMD$ wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip;gzip -cd top-1m.csv.zip|grep alicdn.com ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remediation Plan for WoSign and StartCom
On Wednesday, November 2, 2016 at 5:22:30 PM UTC+2, Gervase Markham wrote: > Hi Daniel, > > On 02/11/16 14:11, Itzhak Daniel wrote: > As far as the DigiCert certs go, it is far too early to have an opinion > on what Mozilla is or isn't doing. I have to agree, the time span is too short (at least they didn't backdate). > I'm not sure what you mean by "ignoring Mozilla Security Community". I > am happy with the level of communication by Comodo about their incident. AFAIK they didn't include the TLD '.re' in their incident report [1] (the certificate was probably issued on Jun 30th, 2014; Google CT 1st seen timestamp: 2014-07-02 14:54:54 GMT [2]), they had the same mistake before the 'sb' incident, but did/do not acknowledge it officially [3]. Links, 1. https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg04274.html 2. https://crt.sh/?id=4467456 3. https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/LQSrnPv2qOo ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remediation Plan for WoSign and StartCom
Interesting that Comodo and DigiCert are getting a different treatment, I wonder if WoSign/StartCom had ignored Mozilla Security Community at some degree, the same way Comodo and DigiCert are doing, would it saved them. (I don't know if there are chatters in the back, maybe I missed something and these issue are already resolved.) Comodo Links: (Their incident report didn't include .re TLD) https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/PoMZvss_PRo DigiCert Links: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/xTKZTDKnNWg https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
