RE: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-11-10 Thread Robin Alden 
Hi Hanno,

Hanno Böck, on 04 October 2016 13:34, said..
> There seem to be more certificates of that kind that weren't mentioned
> in the incident report. Here's a .re / www.re certificate (expired
> 2015):
> https://crt.sh/?id=4467456
> 
> Has comodo checked its systems for other certificates of that kind? Can
> you provide a full list of all such certificates?
> 

Yes, we have.

The initial check was for certificates issued on or after Nov 1st 2015, that 
being the date when internal server names were finally outlawed.  
In certificates issued before that date dNSName=sb could arguably be considered 
an internal server name (given that https://sb/ isn't supposed to
resolve on the public Internet).  At any rate, in the interests of getting the 
incident report out, it was simpler to only go back as far as Nov 1st 2015 so 
that we didn't have to consider internal server names at all.

We took another pass through the data looking for all server authentication 
certificates where we included DOMAIN, and for which DOMAIN is also included in 
the PSL or is a TLD, but where we validated (something).DOMAIN instead of 
DOMAIN.  This should produce a superset of all certificates that exhibit this 
problem.
In each case, the (something) was 'www'.

Going back to 2011, which was when we started checking the PSL in addition to a 
(then) fixed list of TLDs, we find the following certificates:
Issued  PSL section State
25/07/2011  k12.wa.us   ICANN   expired
25/07/2011  k12.wa.us   ICANN   expired
12/11/2011  re  ICANN   expired
10/12/2012  gov.uk  ICANN   expired
02/05/2013  fredrikstad.no  ICANN   expired
10/06/2013  k12.wa.us   ICANN   expired
02/08/2013  ks.ua   ICANN   expired
30/06/2014  re  ICANN   expired
28/08/2014  iki.fi  PRIVATE Valid (still live on https://iki.fi)
17/06/2015  gov.lk  ICANN   expired
20/09/2015  net.kg  ICANN   expired

Plus these ones which were already discussed:
26/11/2015  rivne.uaICANN
03/08/2016  tc  ICANN
03/08/2016  tc  ICANN
03/08/2016  tc  ICANN
21/09/2016  sb  ICANN

Plus three more certificates which turned out to be on the private section of 
the PSL now, but were not in the PSL when we issued the certificates.

> 
> Also my understanding is that the error here was that control over the
> www.[domain] subdomain would indicate control over [domain]. Does that
> mean that this bug could've been used to also get wildcard certificates
> in the form of *.[tld]?

No.  Regardless of other controls, the nature of this bug was that it only 
affected cases where a customer requested www.DOMAIN, because that was the case 
in which we also added DOMAIN into the SAN.

No certificates were issued for *.[tld]

Regards
Robin Alden
Comodo

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-11-10 Thread Robin Alden 
Gervase Markham, on 04 October 2016 07:10, said..
> Thank you for this report.
> 
> On 27/09/16 02:07, Robin Alden wrote:
> > When we use an 'agreed-upon change to website' method to prove
> domain
> > control, we consider proof of control of 'www.' as also
> > proving control of '' (except where '' is a
> > public suffix).
> > We don't give any other sub-domain this treatment, only 'www'.
> > We believe that the currently enforced and audited (pre-ballot 169) BRs
> > permit us to do this under section 3.2.2.4 method 7.
> 
> 3.2.2.4 section 7 says:
> 
> "Using any other method of confirmation, provided that the CA maintains
> documented evidence that the method of confirmation establishes that the
> Applicant is the Domain Name Registrant or has control over the FQDN to
> at least the same level of assurance as those methods previously
described."
> 
> Where does Comodo's documentation of this methodological equivalence
> reside? Is it in your CP/CPS or elsewhere? Could you share it with us
> please?

It previously existed only in unpublished documentation, so far as I am
aware.
Our auditors were aware of it.
Our validation and support staff have freely offered this information to
assist customers in getting certificates validated and issued.

It is now publicly documented at
https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf
and in the knowledgebase article at:
https://support.comodo.com/index.php?/Knowledgebase/Article/View/791/16/alte
rnative-methods-of-domain-control-validation-dcv

Regards
Robin Alden
Comodo

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-11-03 Thread Gervase Markham 
On 18/10/16 19:15, Rob Stradling wrote:
> Hi Hanno.  The questions that you and others have posted are entirely
> reasonable.  Sorry for the delay.  Robin intends to post a reply this week.

It seems like this reply has not yet appeared?

I would like to make sure my initial question about "Where does Comodo's
documentation of this methodological equivalence
reside? etc." is answered.

And also, how does:

"Today we performed an exhaustive search of all the server
authentication certificates we've issued since November 1 2015, and as a
result we found just one further certificate [6] in which we'd included
a public suffix (rivne.ua) due to this bug."

fit with:
https://crt.sh/?id=4467456
?

Why did you stop searching at Nov 1st 2015? It seems like the bug has
been present for longer...

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-18 Thread Rob Stradling 
Hi Hanno.  The questions that you and others have posted are entirely
reasonable.  Sorry for the delay.  Robin intends to post a reply this week.

On 15/10/16 16:56, Hanno Böck wrote:
> Hello,
> 
> I think I have asked two reasonable questions here.
> Can we get an answer?
> 
> On Tue, 4 Oct 2016 14:33:38 +0200
> Hanno Böck  wrote:
> 
>> There seem to be more certificates of that kind that weren't mentioned
>> in the incident report. Here's a .re / www.re certificate (expired
>> 2015):
>> https://crt.sh/?id=4467456
>>
>> Has comodo checked its systems for other certificates of that kind?
>> Can you provide a full list of all such certificates?
>>
>>
>> Also my understanding is that the error here was that control over the
>> www.[domain] subdomain would indicate control over [domain]. Does that
>> mean that this bug could've been used to also get wildcard
>> certificates in the form of *.[tld]?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-15 Thread Hanno Böck 
Hello,

I think I have asked two reasonable questions here.
Can we get an answer?

On Tue, 4 Oct 2016 14:33:38 +0200
Hanno Böck  wrote:

> There seem to be more certificates of that kind that weren't mentioned
> in the incident report. Here's a .re / www.re certificate (expired
> 2015):
> https://crt.sh/?id=4467456
> 
> Has comodo checked its systems for other certificates of that kind?
> Can you provide a full list of all such certificates?
> 
> 
> Also my understanding is that the error here was that control over the
> www.[domain] subdomain would indicate control over [domain]. Does that
> mean that this bug could've been used to also get wildcard
> certificates in the form of *.[tld]?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpEhCBg0LpHm.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-06 Thread Peter Bowen 
On Thu, Oct 6, 2016 at 7:33 AM, Peter Bowen  wrote:
> On Thu, Oct 6, 2016 at 7:29 AM, Rob Stradling  
> wrote:
>> On 04/10/16 19:39, Peter Bowen wrote:
>>> On Tue, Oct 4, 2016 at 6:29 AM, Rob Stradling  
>>> wrote:
 On 04/10/16 13:18, Nick Lamb wrote:
> On Tuesday, 4 October 2016 11:14:01 UTC+1, Rob Stradling  wrote:
>> Neither.  I'd like to run cablint over all certs pre-issuance, but
>> unfortunately it's not practical to do this yet because 1) cablint is
>> too slow and 2) there are some differences of opinion that have been
>> discussed at CABForum but not yet resolved.
>
> Can you expand on what "too slow" would mean here? Or does it tread too 
> much on specific commercial performance criteria you don't want to talk 
> about?

 Running cablint means firing up the Ruby interpreter, then fork/exec'ing
 a separate executable umpteen times.  IIRC, last time I checked, crt.sh
 was only managing to cablint ~10 certs per second.  (Prior to that,
 before I'd figured out a way to avoid having to take the "firing up the
 Ruby interpreter" hit again and again for every single cert, it was only
 managing to cablint ~3 certs per second).
>>>
>>> cablint could be much faster if the asn1 code could be moved in
>>> process.  Doing so requires someone who can work in C and has some
>>> experience building Ruby extensions.  This change would avoid the many
>>> many fork/exec calls during a single certificate lint.
>>>
>>> If anyone is willing to volunteer, I can provide more detail.
>>
>> Woo!  Matt Palmer accepted the challenge...
>>
>> https://github.com/awslabs/certlint/pull/38
>
> And I just finished doing the initial tests.  The fork/exec version
> took 227.427 seconds to check a specific set of certificates.  The
> extension version took 14.306 seconds.A 15x speedup!
>
> I'm going to do some more testing, but this looks amazing!  Matt rocks!
>
> Oh, and it gives better error messages as a side effect ;)

I did some more testing.  Using a single run it now does over 615
certificates per second.  Running 16 in parallel processed 8948 per
second.

So it is pretty fast now :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-06 Thread Rob Stradling 
On 04/10/16 19:39, Peter Bowen wrote:
> On Tue, Oct 4, 2016 at 6:29 AM, Rob Stradling  
> wrote:
>> On 04/10/16 13:18, Nick Lamb wrote:
>>> On Tuesday, 4 October 2016 11:14:01 UTC+1, Rob Stradling  wrote:
 Neither.  I'd like to run cablint over all certs pre-issuance, but
 unfortunately it's not practical to do this yet because 1) cablint is
 too slow and 2) there are some differences of opinion that have been
 discussed at CABForum but not yet resolved.
>>>
>>> Can you expand on what "too slow" would mean here? Or does it tread too 
>>> much on specific commercial performance criteria you don't want to talk 
>>> about?
>>
>> Running cablint means firing up the Ruby interpreter, then fork/exec'ing
>> a separate executable umpteen times.  IIRC, last time I checked, crt.sh
>> was only managing to cablint ~10 certs per second.  (Prior to that,
>> before I'd figured out a way to avoid having to take the "firing up the
>> Ruby interpreter" hit again and again for every single cert, it was only
>> managing to cablint ~3 certs per second).
> 
> cablint could be much faster if the asn1 code could be moved in
> process.  Doing so requires someone who can work in C and has some
> experience building Ruby extensions.  This change would avoid the many
> many fork/exec calls during a single certificate lint.
> 
> If anyone is willing to volunteer, I can provide more detail.

Woo!  Matt Palmer accepted the challenge...

https://github.com/awslabs/certlint/pull/38

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-04 Thread Peter Bowen 
On Tue, Oct 4, 2016 at 6:29 AM, Rob Stradling  wrote:
> On 04/10/16 13:18, Nick Lamb wrote:
>> On Tuesday, 4 October 2016 11:14:01 UTC+1, Rob Stradling  wrote:
>>> Neither.  I'd like to run cablint over all certs pre-issuance, but
>>> unfortunately it's not practical to do this yet because 1) cablint is
>>> too slow and 2) there are some differences of opinion that have been
>>> discussed at CABForum but not yet resolved.
>>
>> Can you expand on what "too slow" would mean here? Or does it tread too much 
>> on specific commercial performance criteria you don't want to talk about?
>
> Running cablint means firing up the Ruby interpreter, then fork/exec'ing
> a separate executable umpteen times.  IIRC, last time I checked, crt.sh
> was only managing to cablint ~10 certs per second.  (Prior to that,
> before I'd figured out a way to avoid having to take the "firing up the
> Ruby interpreter" hit again and again for every single cert, it was only
> managing to cablint ~3 certs per second).

cablint could be much faster if the asn1 code could be moved in
process.  Doing so requires someone who can work in C and has some
experience building Ruby extensions.  This change would avoid the many
many fork/exec calls during a single certificate lint.

If anyone is willing to volunteer, I can provide more detail.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-04 Thread Rob Stradling 
On 04/10/16 13:18, Nick Lamb wrote:
> On Tuesday, 4 October 2016 11:14:01 UTC+1, Rob Stradling  wrote:
>> Neither.  I'd like to run cablint over all certs pre-issuance, but
>> unfortunately it's not practical to do this yet because 1) cablint is
>> too slow and 2) there are some differences of opinion that have been
>> discussed at CABForum but not yet resolved.
> 
> Can you expand on what "too slow" would mean here? Or does it tread too much 
> on specific commercial performance criteria you don't want to talk about?

Running cablint means firing up the Ruby interpreter, then fork/exec'ing
a separate executable umpteen times.  IIRC, last time I checked, crt.sh
was only managing to cablint ~10 certs per second.  (Prior to that,
before I'd figured out a way to avoid having to take the "firing up the
Ruby interpreter" hit again and again for every single cert, it was only
managing to cablint ~3 certs per second).

x509lint is written in C and uses the OpenSSL C API.  IIRC, last time I
checked, crt.sh was managing to x509lint ~100 certs per second.

> AFAIR Comodo's CPS tells subscribers to expect to wait up to TWO days to 
> receive a certificate after completing validation etc.. Now I'm not crazy 
> enough to think Comodo is actually having ordinary subscribers wait around 
> two days, but an extra few seconds ought to be practical for real-world 
> certificate systems I'd have thought.

It's easy to cope with our "normal" rate of certificate issuance.
However, we need to avoid unacceptable backlogs (where "unacceptable" is
defined by customer perception) when our high-volume customers request
large batches of certificates.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-04 Thread Hanno Böck 
Hi,

There seem to be more certificates of that kind that weren't mentioned
in the incident report. Here's a .re / www.re certificate (expired
2015):
https://crt.sh/?id=4467456

Has comodo checked its systems for other certificates of that kind? Can
you provide a full list of all such certificates?


Also my understanding is that the error here was that control over the
www.[domain] subdomain would indicate control over [domain]. Does that
mean that this bug could've been used to also get wildcard certificates
in the form of *.[tld]?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


pgpq26I03NxxI.pgp
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-04 Thread Nick Lamb 
On Tuesday, 4 October 2016 11:14:01 UTC+1, Rob Stradling  wrote:
> Neither.  I'd like to run cablint over all certs pre-issuance, but
> unfortunately it's not practical to do this yet because 1) cablint is
> too slow and 2) there are some differences of opinion that have been
> discussed at CABForum but not yet resolved.

Can you expand on what "too slow" would mean here? Or does it tread too much on 
specific commercial performance criteria you don't want to talk about?

AFAIR Comodo's CPS tells subscribers to expect to wait up to TWO days to 
receive a certificate after completing validation etc.. Now I'm not crazy 
enough to think Comodo is actually having ordinary subscribers wait around two 
days, but an extra few seconds ought to be practical for real-world certificate 
systems I'd have thought.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-04 Thread Rob Stradling 
On 04/10/16 11:51, Kurt Roeckx wrote:
> On Tue, Oct 04, 2016 at 11:13:21AM +0100, Rob Stradling wrote:
>> On 04/10/16 07:10, Gervase Markham wrote:

>>> Does Comodo run cablint over all certificates post-issuance (or 
>>> pre-issuance)?
>>
>> Neither.  I'd like to run cablint over all certs pre-issuance, but
>> unfortunately it's not practical to do this yet because 1) cablint is
>> too slow and 2) there are some differences of opinion that have been
>> discussed at CABForum but not yet resolved.
> 
> I guess you don't have the same slowness with x509lint, but that:
> - It doesn't cover all the same things
> - It might also still give errors about things that CABForum needs
>   to resolve.
> 
> But I guess it should be easy enough for you to ignore some of the
> errors (or warnings).
> 
> I do intend to make it check more things, but activity really
> comes in bursts.

Hi Kurt.  Indeed, x509lint is currently much quicker.  I'd like to run
x509lint over all certs pre-issuance too.  :-)

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-04 Thread Kurt Roeckx 
On Tue, Oct 04, 2016 at 11:13:21AM +0100, Rob Stradling wrote:
> On 04/10/16 07:10, Gervase Markham wrote:
> 
> >> [4] https://crt.sh/?cablint=1+week
> > 
> > This URL is a 404.
> 
> Sorry, crt.sh is a bit under the weather right now.  Someone submitted a
> batch of several million certs to the Google CT logs, and this has
> rather overwhelmed the replication between crt.sh's master DB and slave
> DBs.  The slaves are still catching up at the moment.
> 
> crt.sh queries are occasionally killed off due to some DB replication
> issues that I don't yet fully understand.  Unfortunately, the current
> backlog has exacerbated this problem, hence the high number of 404s.
> 
> crt.sh should be fighting fit again soon though.  :-)
> 
> > Are you simply saying that cablint alerted you to the error?
> 
> Yes.
> 
> > Does Comodo run cablint over all certificates post-issuance (or 
> > pre-issuance)?
> 
> Neither.  I'd like to run cablint over all certs pre-issuance, but
> unfortunately it's not practical to do this yet because 1) cablint is
> too slow and 2) there are some differences of opinion that have been
> discussed at CABForum but not yet resolved.

I guess you don't have the same slowness with x509lint, but that:
- It doesn't cover all the same things
- It might also still give errors about things that CABForum needs
  to resolve.

But I guess it should be easy enough for you to ignore some of the
errors (or warnings).

I do intend to make it check more things, but activity really
comes in bursts.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-04 Thread Rob Stradling 
On 04/10/16 07:10, Gervase Markham wrote:

>> [4] https://crt.sh/?cablint=1+week
> 
> This URL is a 404.

Sorry, crt.sh is a bit under the weather right now.  Someone submitted a
batch of several million certs to the Google CT logs, and this has
rather overwhelmed the replication between crt.sh's master DB and slave
DBs.  The slaves are still catching up at the moment.

crt.sh queries are occasionally killed off due to some DB replication
issues that I don't yet fully understand.  Unfortunately, the current
backlog has exacerbated this problem, hence the high number of 404s.

crt.sh should be fighting fit again soon though.  :-)

> Are you simply saying that cablint alerted you to the error?

Yes.

> Does Comodo run cablint over all certificates post-issuance (or pre-issuance)?

Neither.  I'd like to run cablint over all certs pre-issuance, but
unfortunately it's not practical to do this yet because 1) cablint is
too slow and 2) there are some differences of opinion that have been
discussed at CABForum but not yet resolved.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

2016-10-04 Thread Gervase Markham 
Hi Robin,

Thank you for this report.

On 27/09/16 02:07, Robin Alden wrote:
> When we use an 'agreed-upon change to website' method to prove domain
> control, we consider proof of control of 'www.' as also
> proving control of '' (except where '' is a
> public suffix).
> We don't give any other sub-domain this treatment, only 'www'.
> We believe that the currently enforced and audited (pre-ballot 169) BRs
> permit us to do this under section 3.2.2.4 method 7.

3.2.2.4 section 7 says:

"Using any other method of confirmation, provided that the CA maintains
documented evidence that the method of confirmation establishes that the
Applicant is the Domain Name Registrant or has control over the FQDN to
at least the same level of assurance as those methods previously described."

Where does Comodo's documentation of this methodological equivalence
reside? Is it in your CP/CPS or elsewhere? Could you share it with us
please?

> [4] https://crt.sh/?cablint=1+week

This URL is a 404. Are you simply saying that cablint alerted you to the
error? Does Comodo run cablint over all certificates post-issuance (or
pre-issuance)?

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy