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-...@lists.mozilla.org" <
dev-security-...@lists.mozilla.org> wrote:
>
> Send dev-security-policy mailing list submissions to
>
dev-secur...@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-...@lists.mozilla.org
>
> You can reach the person managing the list at
>
dev-security...@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 <
pzb...@gmail.com>
> To: Gervase Markham <
ge...@mozilla.org>
> Cc: "
mozilla-dev-s...@lists.mozilla.org"
> <
mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: Action on undisclosed intermediates
> Message-ID:
> <
CAK6vND_0OdJSgOa5ZxhxryEG...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
>> On Tue, Nov 8, 2016 at 8:18 AM, Gervase Markham <
ge...@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.st...@comodo.com>
> To: Peter Bowen <
pzb...@gmail.com>, Gervase Markham
> <
ge...@mozilla.org>
> Cc: "
mozilla-dev-s...@lists.mozilla.org"
> <
mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: Action on undisclosed intermediates
> Message-ID: <
734f7b4e-9911-d28e...@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 <
er...@konklone.com>
> To: Robin Alden <
ro...@comodo.com>
> Cc: Nick Lamb <
tiala...@gmail.com>,
> "
mozilla-dev-s...@lists.mozilla.org"
> <
mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: Comodo issued a certificate for an extension
> Message-ID:
> <
CANBOYLUeST3c8sZL62a4wJY2...@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 <
tiala...@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
> ------------------------------
>
> Message: 4
> Date: Sun, 13 Nov 2016 01:08:49 -0800 (PST)
> From: Percy <
percy...@gmail.com>
> To:
mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Apple's response to the WoSign incidents
> Message-ID: <
e741fbd7-8a40-4129...@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
> ------------------------------
>
> End of dev-security-policy Digest, Vol 95, Issue 49
> ***************************************************