Unknown Intermediates

[Tavis Ormandy]

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)

[Rob Stradling]

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

[Jonathan Rudenberg]

> On Jun 16, 2017, at 05:00, Rob Stradling via dev-security-policy <dev-secur...@lists.mozilla.org> 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

[Tavis Ormandy]

On Fri, Jun 16, 2017 at 2:00 AM, Rob Stradling <rob.st...@comodo.com>

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.

[Andrew Ayer]

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

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

[Rob Stradling]

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

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

[Alex Gaynor]

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 <cert1.pem, cert2.pem, ...> 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

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

[Tavis Ormandy]

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.

[Tavis Ormandy]

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.

[Daniel Cater]

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.

[Tavis Ormandy]

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 <tav...@google.com> 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.
>
>

[Rob Stradling]

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.

[Alex Gaynor]

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 <rob.st...@comodo.com>
wrote:

[Tavis Ormandy]

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.

[Alex Gaynor]

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

[Rob Stradling]

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:

<snip>

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

[Kurt Roeckx]

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

[Rob Stradling]

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.

[Peter Bowen]

On Fri, Jun 23, 2017 at 6:17 AM, Rob Stradling via dev-security-policy
<dev-secur...@lists.mozilla.org> 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.

[Jakob Bohm]

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

[Rob Stradling]

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
> <dev-secur...@lists.mozilla.org> 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.

[Bruce]

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.

[Ryan Sleevi]

On Thu, Jun 29, 2017 at 3:56 PM, Bruce via dev-security-policy <
dev-secur...@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.