
Certainty: Automated CACert.pem Management for PHP Software - CiPHPerCoder
https://paragonie.com/blog/2017/10/certainty-automated-cacert-pem-management-for-php-software
======
tottenhm
(Full disclosure: I published [https://packagist.org/packages/totten/ca-
config](https://packagist.org/packages/totten/ca-config) several years ago. I
like how `paragonie/certainty` will do a better job of staying up-to-date in
badly configured systems. But for well configured systems, I sorta prefer the
way `ca-config` defers to the system's CA.)

A few clarifications/suggestions:

1\. Does this verify the bundle's signature everytime one _reads_ the bundle
(ie everytime one uses `curl` + `getLatestBundle()`)? That would feel a little
heavy-handed. Maybe it could check the signature everytime one _downloads_ the
bundle?

2\. Does the default configuration (as written in the docs) really treat
`vendor/paragonie/certainty/data` as a writeable data-folder? So downstream
developers+admins need to set pretty liberal file permissions? (Or perhaps
dig-up a way to use an alternative data directory?) Might be useful for the
docs mention this.

~~~
CiPHPerCoder
> Maybe it could check the signature everytime one downloads the bundle?

Yes, that's probably the direction we're going to go.

> So downstream developers+admins need to set pretty liberal file permissions?
> (Or perhaps dig-up a way to use an alternative data directory?) Might be
> useful for the docs mention this.

That's a good point. Another developer indicated they were writing a pull
request to add composer post-install hooks, and I could easily add one that
chmods this directory.

------
lucideer
This looks to be a replacement for/alternative to
[https://packagist.org/packages/composer/ca-
bundle](https://packagist.org/packages/composer/ca-bundle) which updates certs
every 24 hours instead of at whatever interval you upgrade your system or
update your dependencies.

I'm curious, is this apparent issue of outdated cert bundles also a problem
outside of the PHP ecosystem?

The article leads by talking about people ignorantly disabling validation,
which is fair enough, but using plain old composer/ca-bundle would be a
solution to that without going as far as the per 24 hour updates.

~~~
CiPHPerCoder
> I'm curious, is this apparent issue of outdated cert bundles also a problem
> outside of the PHP ecosystem?

Yes, that is a problem that would exist outside of the PHP ecosystem. We
provided a solution for it in our tool because we strive to be forward-
thinking.

I'm not aware of any systems being breached because of stale cacert.pem files
and the employment of rogue CA certificates, but that's probably due to the
rarity of attackers having access to a rogue/compromised CA, and that
attackers that do are unlikely to get caught very easily.

It may turn out to be the case that this has never happened before and won't
happen in the immediate future, but if a bunch of CAs suddenly get hacked and
their private keys are leaked on Pastebin, then this would of course change
rapidly.

For these scenarios, I can only prescribe something like Expect-CT to force
attackers to leave evidence of their attack behind.
[https://scotthelme.co.uk/a-new-security-header-expect-
ct/](https://scotthelme.co.uk/a-new-security-header-expect-ct/)

------
tialaramex
Ensuring you have some sort of root trust store is a _start_ but probably not
the end for anything but trivial hacks.

The file you know as cacert.pem is a result of processing source code Mozilla
makes available for NSS, the trust component of the Firefox browser.

Now, Mozilla makes its trust decisions in public, on the hybrid newsgroup/
mailing list mozilla.dev.security.policy. But it makes these decisions
_primarily_ as a web browser. The Web PKI (a PKI for things that speak SSL/TLS
over the Internet, not necessarily just the web) overlaps well with that, but
the two aren't quite the same.

Further, Mozilla can and does make trust decisions that go beyond the simple
binary decisions reflected in NSS and thus in cacert.pem. For example, if
Mozilla decides they trust a particular CA to put honest dates in their
certificates, but that their validation regime was too poor to be acceptable
until August 2016, they might tell Firefox to reject certificates from that CA
which say they were issued before that date. But NSS will only mark that CA as
acceptable, and so it'll be included in cacert.pem

If you have a very specialised application you can and should curate your own
trust store. Most people are too lazy, but that's a bad thing. Now, disabling
CA checks altogether is definitely _worse_ than using Mozilla's trust store
blindly, but it is not a panacea.

This isn't PHP-specific. If your application cares whether it's talking to
real.example.com or dubious.example.net then you need to care about trust
stores. They are not very sexy, there is no magic solution, and "Trust
Mozilla" or "Trust my operating system vendor" is, again, better than "I
dunno, let's switch the checks off altogether", but you really ought to do
better.

Apple runs the Podcasting backend that matters for most people. You would
assume that huge multinational corporation Apple carefully curates the trust
store for that right? Er, nope. It's built out of Java apparently, once Oracle
shipped a JDK update that trusted a new CA, magically that CA was trusted by
the Apple podcasting system shortly afterwards.

And by the way apart from the fact that they're the ones who provide source
code ready for download, the other reason people rely on Mozilla these days is
they're open about how this works. If you use the built-in trust on Windows,
or MacOS, you have no insight into their rules, they don't publish anything
beyond the very basics of how to apply to be added to their stores. What are
the acceptance criteria? Nobody knows.

------
wolco
It is an interesting solution to a problem that hasn't really affected many.

The bigger issue is one should not automatically trust packages and should
audit each before using because chances are the attack vector in the source is
a bigger target than a man in the middle attack.

