Re: Unknown Intermediates

[Ryan Sleevi via dev-security-policy]

On Thu, Jun 29, 2017 at 3:56 PM, Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I'm trying to understand this posting. I think the CAs have an obligation
> to disclose all Intermediate certificates to the CCADB. I don't think that
> the CAs have an obligation to disclose through CT. Am I right?
>

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

Re: Unknown Intermediates

[Bruce via dev-security-policy]

On Friday, June 16, 2017 at 1:05:37 AM UTC-4, Tavis Ormandy wrote:
> Hello, I was crawling the pkcs7 blobs in public pdf files and found some
> intermediate certificates that don't appear in crt.sh.
> 
> I forwarded them to Rob, I don't know if this is useful to anyone else, but
> they're available here.
> 
> https://lock.cmpxchg8b.com/intermediates.zip
> 
> Tavis.
> 
> (I have a larger collection if anyone wants them, but many have unknown
> critical extensions, or are name or usage constrained, etc)

I'm trying to understand this posting. I think the CAs have an obligation to 
disclose all Intermediate certificates to the CCADB. I don't think that the CAs 
have an obligation to disclose through CT. Am I right?

I did review the zip above and found 3 Entrust/AffirmTrust certificates. These 
were all disclosed in the CCADB. 

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

Re: Unknown Intermediates

[Rob Stradling via dev-security-policy]

On 23/06/17 14:49, Peter Bowen via dev-security-policy wrote:

On Fri, Jun 23, 2017 at 6:17 AM, Rob Stradling via dev-security-policy
 wrote:

On 23/06/17 14:10, Kurt Roeckx via dev-security-policy wrote:


On 2017-06-23 14:59, Rob Stradling wrote:


Reasons:
- Some are only trusted by the old Adobe CDS program.
- Some are only trusted for Microsoft Kernel Mode Code Signing.
- Some are very old roots that are no longer trusted.



I wonder if Google's daedalus would like to see some of those.



Daedalus only accepts expired certs.  Most of these haven't expired.

If there's interest, I could add these to our Dodo log.


For those three, I would be interested in seeing them.  I wonder if
any match submariner as well.


We've just added the Adobe Root CA and Microsoft Code Verification Root 
to the list of roots accepted by our Dodo log.


--
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: Unknown Intermediates

[Jakob Bohm via dev-security-policy]

On 23/06/2017 14:59, Rob Stradling wrote:

On 22/06/17 10:51, Rob Stradling via dev-security-policy wrote:

On 19/06/17 20:41, Tavis Ormandy via dev-security-policy wrote:



Is this useful? if not, what key usage is interesting?

https://lock.cmpxchg8b.com/ServerOrAny.zip


Thanks for this, Tavis.  I pointed my certscraper 
(https://github.com/robstradling/certscraper) at this URL a couple of 
days ago.  This submitted many of the certs to the Dodo and Rocketeer 
logs.


However, it didn't manage to build chains for all of them.  I haven't 
yet had a chance to investigate why.


There are ~130 CA certificates in 
https://lock.cmpxchg8b.com/ServerOrAny.zip that I've not yet been able 
to submit to any CT logs.


Reasons:
   - Some are only trusted by the old Adobe CDS program.
   - Some are only trusted for Microsoft Kernel Mode Code Signing.
   - Some are very old roots that are no longer trusted.
   - Some are corrupted.
   - Some seem to be from private PKIs.



The SubCAs for Windows 5.01 (XP) to 6.03 (Eight point One) kernel mode
signing are all 10 year cross-certs from a dedicated single-purpose
Microsoft root CA to well known roots from companies like Symantec and
GlobalSign.

They can (or could) be downloaded from a Microsoft support page, I know
of 6 that expired in 2016, 19 that will expire in 2021 and 4 that will
expire in 2023.

The issuing 20 year root is

http://www.microsoft.com/pki/certs/MicrosoftCodeVerifRoot.crt

CN=Microsoft Code Verification Root, O=Microsoft Corporation, L=Redmond, 
ST=Washington, C=US


SHA1 Fingerprint=8F:BE:4D:07:0E:F8:AB:1B:CC:AF:2A:9D:5C:CA:E7:28:2A:2C:66:B3

The relevant root store contains *only* this root, so the issuing (and
possible revocation) of the SubCA/crosscerts acts as a dedicated root
program more restrictive than the normal Microsoft root program.  Chain
validation is often done during boot before TCP/IP is up and running
(even the network drivers are signed with this), so there is no AIA or
OCSP available.  Pre-download CRLs could be checked, but I don't know if
they do that.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Unknown Intermediates

[Peter Bowen via dev-security-policy]

On Fri, Jun 23, 2017 at 6:17 AM, Rob Stradling via dev-security-policy
 wrote:
> On 23/06/17 14:10, Kurt Roeckx via dev-security-policy wrote:
>>
>> On 2017-06-23 14:59, Rob Stradling wrote:
>>>
>>> Reasons:
>>>- Some are only trusted by the old Adobe CDS program.
>>>- Some are only trusted for Microsoft Kernel Mode Code Signing.
>>>- Some are very old roots that are no longer trusted.
>>
>>
>> I wonder if Google's daedalus would like to see some of those.
>
>
> Daedalus only accepts expired certs.  Most of these haven't expired.
>
> If there's interest, I could add these to our Dodo log.

For those three, I would be interested in seeing them.  I wonder if
any match submariner as well.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Unknown Intermediates

[Rob Stradling via dev-security-policy]

On 23/06/17 14:10, Kurt Roeckx via dev-security-policy wrote:

On 2017-06-23 14:59, Rob Stradling wrote:

Reasons:
   - Some are only trusted by the old Adobe CDS program.
   - Some are only trusted for Microsoft Kernel Mode Code Signing.
   - Some are very old roots that are no longer trusted.


I wonder if Google's daedalus would like to see some of those.


Daedalus only accepts expired certs.  Most of these haven't expired.

If there's interest, I could add these to our Dodo log.

--
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: Unknown Intermediates

[Kurt Roeckx via dev-security-policy]

On 2017-06-23 14:59, Rob Stradling wrote:

Reasons:
   - Some are only trusted by the old Adobe CDS program.
   - Some are only trusted for Microsoft Kernel Mode Code Signing.
   - Some are very old roots that are no longer trusted.


I wonder if Google's daedalus would like to see some of those.


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

Re: Unknown Intermediates

[Rob Stradling via dev-security-policy]

On 22/06/17 10:51, Rob Stradling via dev-security-policy wrote:

On 19/06/17 20:41, Tavis Ormandy via dev-security-policy wrote:



Is this useful? if not, what key usage is interesting?

https://lock.cmpxchg8b.com/ServerOrAny.zip


Thanks for this, Tavis.  I pointed my certscraper 
(https://github.com/robstradling/certscraper) at this URL a couple of 
days ago.  This submitted many of the certs to the Dodo and Rocketeer logs.


However, it didn't manage to build chains for all of them.  I haven't 
yet had a chance to investigate why.


There are ~130 CA certificates in 
https://lock.cmpxchg8b.com/ServerOrAny.zip that I've not yet been able 
to submit to any CT logs.


Reasons:
  - Some are only trusted by the old Adobe CDS program.
  - Some are only trusted for Microsoft Kernel Mode Code Signing.
  - Some are very old roots that are no longer trusted.
  - Some are corrupted.
  - Some seem to be from private PKIs.

--
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: Unknown Intermediates

[Alex Gaynor via dev-security-policy]

I definitely consider increased visibility into the vast iceberg that is
the public PKI to be a good thing!

What set of intermediates are you using? If it's reasonably complete, I
doubt we'll do any better than you, though maybe someone here has a
particularly clever technique for processing these.

As these are all from PDFs, an interesting follow-up project for someone
might be to look at S/MIME signatures sent to public mailing lists and
seeing what interesting certificates can be found there.

Alex

On Thu, Jun 22, 2017 at 10:45 AM, Tavis Ormandy  wrote:

> I think you're right, it was probably me submitting my corpus - I hope
> that's a good thing! :-)
>
> I only submitted the ones I could verify, would you be interested in the
> others? Many are clearly not interesting, but others seem like they may be
> interesting if I had an intermediate I haven't seen.
>
> Tavis.
>
>
> On Thu, Jun 22, 2017 at 6:15 AM, Alex Gaynor  wrote:
>
>> One of my hobbies is keeping track of publicly trusted (by any of the
>> major root programs) CAs, for which there are no logged certificates.
>> There's over 1000 of these. In the last day, presumably as a result of
>> these efforts, 50-100 CAs were removed from the list.
>>
>> Cheers,
>> Alex
>>
>> On Thu, Jun 22, 2017 at 5:51 AM, Rob Stradling 
>> wrote:
>>
>>> On 19/06/17 20:41, Tavis Ormandy via dev-security-policy wrote:
>>>
 Thanks Alex, I took a look, it looks like the check pings crt.sh - is
 doing
 that for a large number of certificates acceptable Rob?

>>>
>>> Hi Tavis.  Yes, Alex's tool uses https://crt.sh/gen-add-chain to find a
>>> suitable cert chain and build the JSON that can then be submitted to a
>>> log's /ct/v1/add-chain.  It should be fine to do that for a large number of
>>> certs.  crt.sh exists to be used.  ;-)
>>>
>>> I made a smaller set, the certificates that have 'SSL server: Yes' or
 'Any
 Purpose : Yes', there were only a few thousand that verified, so I just
 checked those and found 551 not in crt.sh.

 (The *vast* majority are code signing certificates, many are individual
 apple developer certificates)

 Is this useful? if not, what key usage is interesting?

 https://lock.cmpxchg8b.com/ServerOrAny.zip

>>>
>>> Thanks for this, Tavis.  I pointed my certscraper (
>>> https://github.com/robstradling/certscraper) at this URL a couple of
>>> days ago.  This submitted many of the certs to the Dodo and Rocketeer logs.
>>>
>>> However, it didn't manage to build chains for all of them.  I haven't
>>> yet had a chance to investigate why.
>>>
>>>
>>> Tavis.

 On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor 
 wrote:

 If you're interested in playing around with submitting them yourself, or
> checking if they're already submitted, I've got some random tools for
> working with CT: https://github.com/alex/ct-tools
>
> Specifically ct-tools check  will get what
> you
> want. It's all serial, so for 8M certs you probably want to Bring Your
> Own
> Parallelism (I should fix this...)
>
> Alex
>
> On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy
> <
> dev-security-policy@lists.mozilla.org> wrote:
>
> On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:
>>
>> On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:
>>>
>>> 
>>
>> Is there an easy way to check which certificates from my set you're
>>>
 missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
 for fuzzing).

 I collected these from public sources, so can just give you my whole
 set if you already have tools for importing them and don't mind
 processing them, I have around ~8M (mostly leaf) certificates, the
 set with isCa will be much smaller.


>>> Please do post the whole set.  I suspect there are several people on
>>> this list (including myself and Rob) who have the tools and
>>> experience
>>> to process large sets of certificates and post them to public
>>> Certificate Transparency logs (whence they will be fed into crt.sh).
>>>
>>> It would be useful to include the leaf certificates as well, to catch
>>> CAs which are engaging in bad practices such as signing non-SSL certs
>>> with SHA-1 under an intermediate that is capable of issuing SSL
>>> certificates.
>>>
>>> Thanks a bunch for this!
>>>
>>>
>> +1
>>
>> Tavis, please do post the whole set.  And thanks!
>>
>
>>> --
>>> Rob Stradling
>>> Senior Research & Development Scientist
>>> COMODO - Creating Trust Online
>>>
>>
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Re: Unknown Intermediates

[Tavis Ormandy via dev-security-policy]

I think you're right, it was probably me submitting my corpus - I hope
that's a good thing! :-)

I only submitted the ones I could verify, would you be interested in the
others? Many are clearly not interesting, but others seem like they may be
interesting if I had an intermediate I haven't seen.

Tavis.

On Thu, Jun 22, 2017 at 6:15 AM, Alex Gaynor  wrote:

> One of my hobbies is keeping track of publicly trusted (by any of the
> major root programs) CAs, for which there are no logged certificates.
> There's over 1000 of these. In the last day, presumably as a result of
> these efforts, 50-100 CAs were removed from the list.
>
> Cheers,
> Alex
>
> On Thu, Jun 22, 2017 at 5:51 AM, Rob Stradling 
> wrote:
>
>> On 19/06/17 20:41, Tavis Ormandy via dev-security-policy wrote:
>>
>>> Thanks Alex, I took a look, it looks like the check pings crt.sh - is
>>> doing
>>> that for a large number of certificates acceptable Rob?
>>>
>>
>> Hi Tavis.  Yes, Alex's tool uses https://crt.sh/gen-add-chain to find a
>> suitable cert chain and build the JSON that can then be submitted to a
>> log's /ct/v1/add-chain.  It should be fine to do that for a large number of
>> certs.  crt.sh exists to be used.  ;-)
>>
>> I made a smaller set, the certificates that have 'SSL server: Yes' or 'Any
>>> Purpose : Yes', there were only a few thousand that verified, so I just
>>> checked those and found 551 not in crt.sh.
>>>
>>> (The *vast* majority are code signing certificates, many are individual
>>> apple developer certificates)
>>>
>>> Is this useful? if not, what key usage is interesting?
>>>
>>> https://lock.cmpxchg8b.com/ServerOrAny.zip
>>>
>>
>> Thanks for this, Tavis.  I pointed my certscraper (
>> https://github.com/robstradling/certscraper) at this URL a couple of
>> days ago.  This submitted many of the certs to the Dodo and Rocketeer logs.
>>
>> However, it didn't manage to build chains for all of them.  I haven't yet
>> had a chance to investigate why.
>>
>>
>> Tavis.
>>>
>>> On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor 
>>> wrote:
>>>
>>> If you're interested in playing around with submitting them yourself, or
 checking if they're already submitted, I've got some random tools for
 working with CT: https://github.com/alex/ct-tools

 Specifically ct-tools check  will get what
 you
 want. It's all serial, so for 8M certs you probably want to Bring Your
 Own
 Parallelism (I should fix this...)

 Alex

 On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
 dev-security-policy@lists.mozilla.org> wrote:

 On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:
>
> On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:
>>
>> 
>
> Is there an easy way to check which certificates from my set you're
>>
>>> missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
>>> for fuzzing).
>>>
>>> I collected these from public sources, so can just give you my whole
>>> set if you already have tools for importing them and don't mind
>>> processing them, I have around ~8M (mostly leaf) certificates, the
>>> set with isCa will be much smaller.
>>>
>>>
>> Please do post the whole set.  I suspect there are several people on
>> this list (including myself and Rob) who have the tools and experience
>> to process large sets of certificates and post them to public
>> Certificate Transparency logs (whence they will be fed into crt.sh).
>>
>> It would be useful to include the leaf certificates as well, to catch
>> CAs which are engaging in bad practices such as signing non-SSL certs
>> with SHA-1 under an intermediate that is capable of issuing SSL
>> certificates.
>>
>> Thanks a bunch for this!
>>
>>
> +1
>
> Tavis, please do post the whole set.  And thanks!
>

>> --
>> 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: Unknown Intermediates

[Alex Gaynor via dev-security-policy]

One of my hobbies is keeping track of publicly trusted (by any of the major
root programs) CAs, for which there are no logged certificates. There's
over 1000 of these. In the last day, presumably as a result of these
efforts, 50-100 CAs were removed from the list.

Cheers,
Alex

On Thu, Jun 22, 2017 at 5:51 AM, Rob Stradling 
wrote:

> On 19/06/17 20:41, Tavis Ormandy via dev-security-policy wrote:
>
>> Thanks Alex, I took a look, it looks like the check pings crt.sh - is
>> doing
>> that for a large number of certificates acceptable Rob?
>>
>
> Hi Tavis.  Yes, Alex's tool uses https://crt.sh/gen-add-chain to find a
> suitable cert chain and build the JSON that can then be submitted to a
> log's /ct/v1/add-chain.  It should be fine to do that for a large number of
> certs.  crt.sh exists to be used.  ;-)
>
> I made a smaller set, the certificates that have 'SSL server: Yes' or 'Any
>> Purpose : Yes', there were only a few thousand that verified, so I just
>> checked those and found 551 not in crt.sh.
>>
>> (The *vast* majority are code signing certificates, many are individual
>> apple developer certificates)
>>
>> Is this useful? if not, what key usage is interesting?
>>
>> https://lock.cmpxchg8b.com/ServerOrAny.zip
>>
>
> Thanks for this, Tavis.  I pointed my certscraper (
> https://github.com/robstradling/certscraper) at this URL a couple of days
> ago.  This submitted many of the certs to the Dodo and Rocketeer logs.
>
> However, it didn't manage to build chains for all of them.  I haven't yet
> had a chance to investigate why.
>
>
> Tavis.
>>
>> On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor  wrote:
>>
>> If you're interested in playing around with submitting them yourself, or
>>> checking if they're already submitted, I've got some random tools for
>>> working with CT: https://github.com/alex/ct-tools
>>>
>>> Specifically ct-tools check  will get what you
>>> want. It's all serial, so for 8M certs you probably want to Bring Your
>>> Own
>>> Parallelism (I should fix this...)
>>>
>>> Alex
>>>
>>> On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>> On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:

 On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:
>
> 

 Is there an easy way to check which certificates from my set you're
>
>> missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
>> for fuzzing).
>>
>> I collected these from public sources, so can just give you my whole
>> set if you already have tools for importing them and don't mind
>> processing them, I have around ~8M (mostly leaf) certificates, the
>> set with isCa will be much smaller.
>>
>>
> Please do post the whole set.  I suspect there are several people on
> this list (including myself and Rob) who have the tools and experience
> to process large sets of certificates and post them to public
> Certificate Transparency logs (whence they will be fed into crt.sh).
>
> It would be useful to include the leaf certificates as well, to catch
> CAs which are engaging in bad practices such as signing non-SSL certs
> with SHA-1 under an intermediate that is capable of issuing SSL
> certificates.
>
> Thanks a bunch for this!
>
>
 +1

 Tavis, please do post the whole set.  And thanks!

>>>
> --
> 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: Unknown Intermediates

[Rob Stradling via dev-security-policy]

On 19/06/17 20:41, Tavis Ormandy via dev-security-policy wrote:

Thanks Alex, I took a look, it looks like the check pings crt.sh - is doing
that for a large number of certificates acceptable Rob?


Hi Tavis.  Yes, Alex's tool uses https://crt.sh/gen-add-chain to find a 
suitable cert chain and build the JSON that can then be submitted to a 
log's /ct/v1/add-chain.  It should be fine to do that for a large number 
of certs.  crt.sh exists to be used.  ;-)



I made a smaller set, the certificates that have 'SSL server: Yes' or 'Any
Purpose : Yes', there were only a few thousand that verified, so I just
checked those and found 551 not in crt.sh.

(The *vast* majority are code signing certificates, many are individual
apple developer certificates)

Is this useful? if not, what key usage is interesting?

https://lock.cmpxchg8b.com/ServerOrAny.zip


Thanks for this, Tavis.  I pointed my certscraper 
(https://github.com/robstradling/certscraper) at this URL a couple of 
days ago.  This submitted many of the certs to the Dodo and Rocketeer logs.


However, it didn't manage to build chains for all of them.  I haven't 
yet had a chance to investigate why.



Tavis.

On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor  wrote:


If you're interested in playing around with submitting them yourself, or
checking if they're already submitted, I've got some random tools for
working with CT: https://github.com/alex/ct-tools

Specifically ct-tools check  will get what you
want. It's all serial, so for 8M certs you probably want to Bring Your Own
Parallelism (I should fix this...)

Alex

On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:


On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:





Is there an easy way to check which certificates from my set you're

missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
for fuzzing).

I collected these from public sources, so can just give you my whole
set if you already have tools for importing them and don't mind
processing them, I have around ~8M (mostly leaf) certificates, the
set with isCa will be much smaller.



Please do post the whole set.  I suspect there are several people on
this list (including myself and Rob) who have the tools and experience
to process large sets of certificates and post them to public
Certificate Transparency logs (whence they will be fed into crt.sh).

It would be useful to include the leaf certificates as well, to catch
CAs which are engaging in bad practices such as signing non-SSL certs
with SHA-1 under an intermediate that is capable of issuing SSL
certificates.

Thanks a bunch for this!



+1

Tavis, please do post the whole set.  And thanks!


--
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: Unknown Intermediates

[Tavis Ormandy via dev-security-policy]

FYI, I'm submitting these right now, it seems to be working, here's an
example

https://crt.sh/?q=1eb6ec6e6c45663f3bb1b2f140961bbf3352fc8741ef835146d3a8a2616ee28f

Tavis.

On Mon, Jun 19, 2017 at 12:56 PM, Tavis Ormandy  wrote:

> I noticed there's an apparently valid facebook.com certificate in there (
> 61b1526f9d75775c3d533382f36527c9.pem). This is surprising to me, that
> seems like it would be in CT already - so maybe I don't know what I'm doing.
>
> Let me know if I've misunderstood something.
>
> Tavis.
>
>
> On Mon, Jun 19, 2017 at 12:41 PM, Tavis Ormandy  wrote:
>
>> Thanks Alex, I took a look, it looks like the check pings crt.sh - is
>> doing that for a large number of certificates acceptable Rob?
>>
>> I made a smaller set, the certificates that have 'SSL server: Yes' or
>> 'Any Purpose : Yes', there were only a few thousand that verified, so I
>> just checked those and found 551 not in crt.sh.
>>
>> (The *vast* majority are code signing certificates, many are individual
>> apple developer certificates)
>>
>> Is this useful? if not, what key usage is interesting?
>>
>> https://lock.cmpxchg8b.com/ServerOrAny.zip
>>
>> Tavis.
>>
>> On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor  wrote:
>>
>>> If you're interested in playing around with submitting them yourself, or
>>> checking if they're already submitted, I've got some random tools for
>>> working with CT: https://github.com/alex/ct-tools
>>>
>>> Specifically ct-tools check  will get what
>>> you want. It's all serial, so for 8M certs you probably want to Bring Your
>>> Own Parallelism (I should fix this...)
>>>
>>> Alex
>>>
>>> On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
 On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:

> On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:
>
 

> Is there an easy way to check which certificates from my set you're
>> missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
>> for fuzzing).
>>
>> I collected these from public sources, so can just give you my whole
>> set if you already have tools for importing them and don't mind
>> processing them, I have around ~8M (mostly leaf) certificates, the
>> set with isCa will be much smaller.
>>
>
> Please do post the whole set.  I suspect there are several people on
> this list (including myself and Rob) who have the tools and experience
> to process large sets of certificates and post them to public
> Certificate Transparency logs (whence they will be fed into crt.sh).
>
> It would be useful to include the leaf certificates as well, to catch
> CAs which are engaging in bad practices such as signing non-SSL certs
> with SHA-1 under an intermediate that is capable of issuing SSL
> certificates.
>
> Thanks a bunch for this!
>

 +1

 Tavis, please do post the whole set.  And thanks!

 --
 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

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

Re: Unknown Intermediates

[Daniel Cater via dev-security-policy]

On Monday, 19 June 2017 20:57:28 UTC+1, Tavis Ormandy  wrote:
> I noticed there's an apparently valid facebook.com certificate in there
> (61b1526f9d75775c3d533382f36527c9.pem). This is surprising to me, that
> seems like it would be in CT already - so maybe I don't know what I'm doing.
> 
> Let me know if I've misunderstood something.
> 
> Tavis.

Thanks for uploading these. I submitted that one in particular which can now be 
seen here: https://crt.sh/?id=157454198

This is the certificate for a precertificate which was already in the CT logs: 
https://crt.sh/?id=81124044 (crt.sh handily has links in both directions 
between both certificates now that it knows about both) and the issuance is 
therefore "known" already, but the final signed certificate was not seen by any 
logs. It is useful to have the final certificate now as well.

I haven't looked at any of the others, but I imagine this case only covers a 
small percentage of the total. When someone here with a more automated approach 
to submitting the certificates (along with their intermediates) analyses them I 
imagine we will see some interesting results.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Unknown Intermediates

[Tavis Ormandy via dev-security-policy]

I noticed there's an apparently valid facebook.com certificate in there
(61b1526f9d75775c3d533382f36527c9.pem). This is surprising to me, that
seems like it would be in CT already - so maybe I don't know what I'm doing.

Let me know if I've misunderstood something.

Tavis.

On Mon, Jun 19, 2017 at 12:41 PM, Tavis Ormandy  wrote:

> Thanks Alex, I took a look, it looks like the check pings crt.sh - is
> doing that for a large number of certificates acceptable Rob?
>
> I made a smaller set, the certificates that have 'SSL server: Yes' or 'Any
> Purpose : Yes', there were only a few thousand that verified, so I just
> checked those and found 551 not in crt.sh.
>
> (The *vast* majority are code signing certificates, many are individual
> apple developer certificates)
>
> Is this useful? if not, what key usage is interesting?
>
> https://lock.cmpxchg8b.com/ServerOrAny.zip
>
> Tavis.
>
> On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor  wrote:
>
>> If you're interested in playing around with submitting them yourself, or
>> checking if they're already submitted, I've got some random tools for
>> working with CT: https://github.com/alex/ct-tools
>>
>> Specifically ct-tools check  will get what you
>> want. It's all serial, so for 8M certs you probably want to Bring Your Own
>> Parallelism (I should fix this...)
>>
>> Alex
>>
>> On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:
>>>
 On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:

>>> 
>>>
 Is there an easy way to check which certificates from my set you're
> missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
> for fuzzing).
>
> I collected these from public sources, so can just give you my whole
> set if you already have tools for importing them and don't mind
> processing them, I have around ~8M (mostly leaf) certificates, the
> set with isCa will be much smaller.
>

 Please do post the whole set.  I suspect there are several people on
 this list (including myself and Rob) who have the tools and experience
 to process large sets of certificates and post them to public
 Certificate Transparency logs (whence they will be fed into crt.sh).

 It would be useful to include the leaf certificates as well, to catch
 CAs which are engaging in bad practices such as signing non-SSL certs
 with SHA-1 under an intermediate that is capable of issuing SSL
 certificates.

 Thanks a bunch for this!

>>>
>>> +1
>>>
>>> Tavis, please do post the whole set.  And thanks!
>>>
>>> --
>>> 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
>>>
>>
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Unknown Intermediates

[Tavis Ormandy via dev-security-policy]

Thanks Alex, I took a look, it looks like the check pings crt.sh - is doing
that for a large number of certificates acceptable Rob?

I made a smaller set, the certificates that have 'SSL server: Yes' or 'Any
Purpose : Yes', there were only a few thousand that verified, so I just
checked those and found 551 not in crt.sh.

(The *vast* majority are code signing certificates, many are individual
apple developer certificates)

Is this useful? if not, what key usage is interesting?

https://lock.cmpxchg8b.com/ServerOrAny.zip

Tavis.

On Mon, Jun 19, 2017 at 7:03 AM, Alex Gaynor  wrote:

> If you're interested in playing around with submitting them yourself, or
> checking if they're already submitted, I've got some random tools for
> working with CT: https://github.com/alex/ct-tools
>
> Specifically ct-tools check  will get what you
> want. It's all serial, so for 8M certs you probably want to Bring Your Own
> Parallelism (I should fix this...)
>
> Alex
>
> On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:
>>
>>> On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:
>>>
>> 
>>
>>> Is there an easy way to check which certificates from my set you're
 missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
 for fuzzing).

 I collected these from public sources, so can just give you my whole
 set if you already have tools for importing them and don't mind
 processing them, I have around ~8M (mostly leaf) certificates, the
 set with isCa will be much smaller.

>>>
>>> Please do post the whole set.  I suspect there are several people on
>>> this list (including myself and Rob) who have the tools and experience
>>> to process large sets of certificates and post them to public
>>> Certificate Transparency logs (whence they will be fed into crt.sh).
>>>
>>> It would be useful to include the leaf certificates as well, to catch
>>> CAs which are engaging in bad practices such as signing non-SSL certs
>>> with SHA-1 under an intermediate that is capable of issuing SSL
>>> certificates.
>>>
>>> Thanks a bunch for this!
>>>
>>
>> +1
>>
>> Tavis, please do post the whole set.  And thanks!
>>
>> --
>> 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
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Unknown Intermediates

[Alex Gaynor via dev-security-policy]

If you're interested in playing around with submitting them yourself, or
checking if they're already submitted, I've got some random tools for
working with CT: https://github.com/alex/ct-tools

Specifically ct-tools check  will get what you
want. It's all serial, so for 8M certs you probably want to Bring Your Own
Parallelism (I should fix this...)

Alex

On Mon, Jun 19, 2017 at 6:51 AM, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 16/06/17 20:11, Andrew Ayer via dev-security-policy wrote:
>
>> On Fri, 16 Jun 2017 10:29:45 -0700 Tavis Ormandy wrote:
>>
> 
>
>> Is there an easy way to check which certificates from my set you're
>>> missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
>>> for fuzzing).
>>>
>>> I collected these from public sources, so can just give you my whole
>>> set if you already have tools for importing them and don't mind
>>> processing them, I have around ~8M (mostly leaf) certificates, the
>>> set with isCa will be much smaller.
>>>
>>
>> Please do post the whole set.  I suspect there are several people on
>> this list (including myself and Rob) who have the tools and experience
>> to process large sets of certificates and post them to public
>> Certificate Transparency logs (whence they will be fed into crt.sh).
>>
>> It would be useful to include the leaf certificates as well, to catch
>> CAs which are engaging in bad practices such as signing non-SSL certs
>> with SHA-1 under an intermediate that is capable of issuing SSL
>> certificates.
>>
>> Thanks a bunch for this!
>>
>
> +1
>
> Tavis, please do post the whole set.  And thanks!
>
> --
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Unknown Intermediates

[Andrew Ayer via dev-security-policy]

On Fri, 16 Jun 2017 10:29:45 -0700
Tavis Ormandy via dev-security-policy
 wrote:

> On Fri, Jun 16, 2017 at 2:00 AM, Rob Stradling
>  wrote:
> 
> > On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote:
> >
> >> Hello, I was crawling the pkcs7 blobs in public pdf files and
> >> found some intermediate certificates that don't appear in crt.sh.
> >>
> >> I forwarded them to Rob, I don't know if this is useful to anyone
> >> else, but
> >> they're available here.
> >>
> >> https://lock.cmpxchg8b.com/intermediates.zip
> >>
> >> Tavis.
> >>
> >
> > Thanks Tavis.  I've just submitted all of these intermediates to
> > some CT logs.
> >
> > This list just grew considerably...
> > https://crt.sh/mozilla-disclosures#undisclosed
> >
> > (I have a larger collection if anyone wants them, but many have
> > unknown
> >> critical extensions, or are name or usage constrained, etc)
> >>
> >
> > Yes please.  :-)
> >
> >
> Is there an easy way to check which certificates from my set you're
> missing? (I'm not a PKI guy, I was collecting unusual extension OIDs
> for fuzzing).
> 
> I collected these from public sources, so can just give you my whole
> set if you already have tools for importing them and don't mind
> processing them, I have around ~8M (mostly leaf) certificates, the
> set with isCa will be much smaller.

Please do post the whole set.  I suspect there are several people on
this list (including myself and Rob) who have the tools and experience
to process large sets of certificates and post them to public
Certificate Transparency logs (whence they will be fed into crt.sh).

It would be useful to include the leaf certificates as well, to catch
CAs which are engaging in bad practices such as signing non-SSL certs
with SHA-1 under an intermediate that is capable of issuing SSL
certificates.

Thanks a bunch for this!

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

Re: Unknown Intermediates

[Tavis Ormandy via dev-security-policy]

On Fri, Jun 16, 2017 at 2:00 AM, Rob Stradling 
wrote:

> On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote:
>
>> Hello, I was crawling the pkcs7 blobs in public pdf files and found some
>> intermediate certificates that don't appear in crt.sh.
>>
>> I forwarded them to Rob, I don't know if this is useful to anyone else,
>> but
>> they're available here.
>>
>> https://lock.cmpxchg8b.com/intermediates.zip
>>
>> Tavis.
>>
>
> Thanks Tavis.  I've just submitted all of these intermediates to some CT
> logs.
>
> This list just grew considerably...
> https://crt.sh/mozilla-disclosures#undisclosed
>
> (I have a larger collection if anyone wants them, but many have unknown
>> critical extensions, or are name or usage constrained, etc)
>>
>
> Yes please.  :-)
>
>
Is there an easy way to check which certificates from my set you're
missing? (I'm not a PKI guy, I was collecting unusual extension OIDs for
fuzzing).

I collected these from public sources, so can just give you my whole set if
you already have tools for importing them and don't mind processing them, I
have around ~8M (mostly leaf) certificates, the set with isCa will be much
smaller.

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

Re: Unknown Intermediates

[Jonathan Rudenberg via dev-security-policy]

> On Jun 16, 2017, at 05:00, Rob Stradling via dev-security-policy 
>  wrote:
> 
> On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote:
>> Hello, I was crawling the pkcs7 blobs in public pdf files and found some
>> intermediate certificates that don't appear in crt.sh.
>> I forwarded them to Rob, I don't know if this is useful to anyone else, but
>> they're available here.
>> https://lock.cmpxchg8b.com/intermediates.zip
>> Tavis.
> 
> Thanks Tavis.  I've just submitted all of these intermediates to some CT logs.
> 
> This list just grew considerably...
> https://crt.sh/mozilla-disclosures#undisclosed

For posterity, here are the new ones (from June 14 to present, there are seven 
others predating this batch that are still on the list):

- 
https://crt.sh/?sha256=a6ca043d5c838dd10e935acdd1079c9686b6511faf4c80c4dcfc9c54394ded5e
- 
https://crt.sh/?sha256=6365b25e9299b5f382eb0066850629088ebcd9bcb398f28622107603c3c1c27e
- 
https://crt.sh/?sha256=d57b9872b1eef8e8032ab2e8cb0e63b685d1655c51c454f23f9975dfa2ad7e0a
- 
https://crt.sh/?sha256=077b75f6b7fa71be4f8121e1ec52faebca0d0aed2dc01711a0f6dcdc38e7bf38
- 
https://crt.sh/?sha256=7fa8450051bac3efd7ea4dbbd070075d7e7b7d27f3f119e6fa1f7103b8a89f24
- 
https://crt.sh/?sha256=3b84290532c84b7026e06a427b689c69fe24154bdecb43fedbe29bf955ca6513
- 
https://crt.sh/?sha256=5d1f493bb09823decc8a6e35a23d04c83778d854a43b34686a363d6f4bb287c2

I think it would be useful to see incident reports from each of the CAs so that 
we can understand how these trusted intermediate certificates, all issued 
several years ago, were missed.

Jonathan


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

Re: Unknown Intermediates

[Rob Stradling via dev-security-policy]

On 16/06/17 06:05, Tavis Ormandy via dev-security-policy wrote:

Hello, I was crawling the pkcs7 blobs in public pdf files and found some
intermediate certificates that don't appear in crt.sh.

I forwarded them to Rob, I don't know if this is useful to anyone else, but
they're available here.

https://lock.cmpxchg8b.com/intermediates.zip

Tavis.


Thanks Tavis.  I've just submitted all of these intermediates to some CT 
logs.


This list just grew considerably...
https://crt.sh/mozilla-disclosures#undisclosed


(I have a larger collection if anyone wants them, but many have unknown
critical extensions, or are name or usage constrained, etc)


Yes please.  :-)

--
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