If Apple is using wildcards that permit an otherwise-banned certificate, it seems like not only a regex problem--and who hasn¹t had those before?-- but also a rather disturbing workaround for certs that otherwise should not be respected. I just hit this site in Safari on a Mac and got no popup or interstitial but also saw about 20 insecure content errors (not that everyone has Error Console running all the time). I also just hit a site I knew had an invalid certificate, and got a popup. Both sites show https inURL.
Respectfully, Tarah Wheeler Principal Security Advocate Senior Director of Engineering, Website Security Symantec ta...@symantec.com > On Nov 13, 2016, at 1:01 PM, "dev-security-policy-requ...@lists.mozilla.org" > <dev-security-policy-requ...@lists.mozilla.org> wrote: > > Send dev-security-policy mailing list submissions to > dev-security-policy@lists.mozilla.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.mozilla.org/listinfo/dev-security-policy > or, via email, send a message with subject or body 'help' to > dev-security-policy-requ...@lists.mozilla.org > > You can reach the person managing the list at > dev-security-policy-ow...@lists.mozilla.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dev-security-policy digest..." > > > Today's Topics: > > 1. Re: Action on undisclosed intermediates (Peter Bowen) > 2. Re: Action on undisclosed intermediates (Rob Stradling) > 3. Re: Comodo issued a certificate for an extension (Eric Mill) > 4. Re: Apple's response to the WoSign incidents (Percy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 12 Nov 2016 09:43:36 -0800 > From: Peter Bowen <pzbo...@gmail.com> > To: Gervase Markham <g...@mozilla.org> > Cc: "mozilla-dev-security-pol...@lists.mozilla.org" > <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Action on undisclosed intermediates > Message-ID: > <cak6vnd_0odjsgoa5zxhxryeghtskaeccij76mco3q_vkrtj...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > >> On Tue, Nov 8, 2016 at 8:18 AM, Gervase Markham <g...@mozilla.org> wrote: >> I'd like to take some action about persistent failures to properly >> disclose intermediates. The deadline for this was June, and CAs have had >> a number of reminders, so there's no excuse. >> >> Of course, if intermediates aren't disclosed, we can't be certain what >> they are, but crt.sh has a good idea of many of them: >> https://crt.sh/mozilla-disclosures#undisclosed >> >> There is also a list on that page of certs which CAs have disclosed but >> not provided audit info, but given that you can get off that list by >> putting _anything_ in the relevant box in Salesforce, I'm worried about >> perverse incentives if we go after people on that list at the moment: >> https://crt.sh/mozilla-disclosures#disclosureincomplete > > Based on data this morning, it looks like there are only two left on > that undisclosed list. One of them is RSA, who is already scheduled > for removal. The other is TurkTrust, which announced they are leaving > the server auth cert business: > https://cabforum.org/pipermail/public/2016-September/008475.html > > So it seems this problem has resolved itself. No need to invent > random selection schemes. > > Now, the real fun is going to be seeing if the supplied audit report > URLs actually point to reports and if all the CAs claimed to be > covered are actually covered ;) > > Thanks, > Peter > > > ------------------------------ > > Message: 2 > Date: Sat, 12 Nov 2016 20:11:50 +0000 > From: Rob Stradling <rob.stradl...@comodo.com> > To: Peter Bowen <pzbo...@gmail.com>, Gervase Markham > <g...@mozilla.org> > Cc: "mozilla-dev-security-pol...@lists.mozilla.org" > <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Action on undisclosed intermediates > Message-ID: <734f7b4e-9911-d28e-acdc-a95afa440...@comodo.com> > Content-Type: text/plain; charset=windows-1252 > >> On 12/11/16 17:43, Peter Bowen wrote: >> <snip> >> So it seems this problem has resolved itself. No need to invent >> random selection schemes. > > ISTM that the threat of random selection schemes may have been what > resolved the problem. ;-) > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > > ------------------------------ > > Message: 3 > Date: Sat, 12 Nov 2016 23:12:48 -0500 > From: Eric Mill <e...@konklone.com> > To: Robin Alden <ro...@comodo.com> > Cc: Nick Lamb <tialara...@gmail.com>, > "mozilla-dev-security-pol...@lists.mozilla.org" > <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Comodo issued a certificate for an extension > Message-ID: > <canboyluest3c8szl62a4wjy2b9v-0c0dcuzfcxx0ark+920...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Thank you for the update and for making it super clear, Robin. > > -- Eric > >> On Thu, Nov 10, 2016 at 2:52 PM, Robin Alden <ro...@comodo.com> wrote: >> >> Eric Mill, on 03 October 2016 03:14, said.. >>>>> On Sun, Oct 2, 2016 at 9:23 PM, Nick Lamb <tialara...@gmail.com> wrote: >>>>> On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen wrote: >>>>> There is some good news. The CA/Browser Forum has already addressed >>>>> this, even prior to the current discussions. Ballot 169 >>>>> (https://cabforum.org/2016/08/05/ballot-169-revised- >>>> validation-requirements/) >>>>> revises 3.2.2.4 considerably. >>>> >>>> I'm aware of Ballot 169 >>>> >>>>> Under the new rules, which should be in >>>>> effect as of 1 March 2017, validating www.<domain> will not be a >> valid >>>>> method of showing control of <domain>. The name is true for any >> valid >>>>> hostname under <domain>. The only note is that names in the form >>>>> _<something>.<domain> (that is starting with an underscore) can be >>>>> used to validate <domain>. >>>> >>>> I wish I shared your confidence. My expectation is that if we leave >> this >>>> as it is, in April 2017 subscribers will still be able to get a >> certificate >>>> issued using this lackadaisical validation, and the issuing CA will say >>>> they feel it's not "really" disobeying the rules, that it's just a >>>> "technicality" and anyway what's the harm, it's so much more convenient >>> for >>>> their customers this way? >>>> >>>> Comodo's document never actually says that they're abolishing this >> "rule" >>>> as a result of Ballot 169. It lets you choose to draw that implication, >> by >>>> specifying that their current practices pre-date Ballot 169's changes, >> but >>>> it never says as much. Hence I think Mozilla's rep should take this to >>>> CA/B, or it should go in one of the bulk CA communications, to find out >> at >>>> least how widespread the crazy is and whether it's even consistent in >> how >>>> it works from one CA to the next. >>> >>> It would be nice for Comodo to make it explicit that this practice will >>> cease when Ballot 169 takes effect, and the lack of an explicit update >>> jumped out at me immediately when I read it. But the BRs post-169 seem >>> crystal clear on this, and I don't think CAs would be able to write off >>> this practice as a technicality or misinterpretation. >>> >>> -- Eric >> >> I'm happy to state definitively that this practice will cease when Ballot >> 169 takes effect. >> >> To avoid suggestions of weasel-words around the CA/B forum's struggle with >> their IP policy my understanding is that at least Microsoft, and I hope >> other browsers too, will incorporate the Ballot 169 wording into their >> policy regardless of whether the CA/B has ratified it by then. >> >> Comodo will have implemented some or all of the new validation methods >> described in Ballot 169 before 1 March 2017. >> Comodo will be withdrawing any and all validation methods which do not >> conform with Ballot 169, and/or which rely on the pre-Ballot 169 3.2.2.4.7 >> 'any-other-equivalent method' rule before 1 March 2017. >> >> Regards >> Robin Alden >> Comodo > > > -- > konklone.com | @konklone <https://twitter.com/konklone> > > > ------------------------------ > > Message: 4 > Date: Sun, 13 Nov 2016 01:08:49 -0800 (PST) > From: Percy <percyal...@gmail.com> > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Apple's response to the WoSign incidents > Message-ID: <e741fbd7-8a40-4129-bd7f-71d19d05f...@googlegroups.com> > Content-Type: text/plain; charset=UTF-8 > > I just found out that Apple doesn't limit "CA ????SSL?? G2" intermediate CA > even though Apple limited "WoSign CA Free SSL Certificate G2" intermediate > CA. An example of site signed by"CA ????SSL?? G2" intermediate CA is > https://www.chelenet.com/ > > Those two intermediate certs are treated by WoSign the same way and the > translation of "CA ????SSL?? G2" is "WoSign CA Free SSL Certificate G2". > Users can select whether the end cert is signed by "CA ????SSL?? G2" or > "WoSign CA Free SSL Certificate G2". All control measures are the same and > the only difference is the language for marketing reasons. > > Hence, because Apple has chose to blocked "WoSign CA Free SSL Certificate > G2", it makes sense to apply the same sanction on "CA ????SSL?? G2", as > they're in all senses the same. > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > > > ------------------------------ > > End of dev-security-policy Digest, Vol 95, Issue 49 > *************************************************** _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
