4 ms·

Certainty: Automated CACert.pem Management for PHP Software

25 points by CiPHPerCoder 9y ago

lucideer 9y ago
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 9y ago
  > 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/
wolco 9y ago
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.
tialaramex 9y ago
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.
tottenhm 9y ago
(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 9y ago
  > 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.
- CiPHPerCoder 9y ago
  https://github.com/paragonie/certainty/commit/005181f421ca8fbb95475e9c6fa6e75f82986c2b https://github.com/paragonie/certainty/commit/005181f421ca8f... :)

25 points by CiPHPerCoder 9y ago

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 9y ago
> 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/

wolco 9y ago

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.

tialaramex 9y ago

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.

tottenhm 9y ago

(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 9y ago
> 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.
CiPHPerCoder 9y ago
https://github.com/paragonie/certainty/commit/005181f421ca8fbb95475e9c6fa6e75f82986c2b https://github.com/paragonie/certainty/commit/005181f421ca8f... :)