Use system cert by default for SSL

[catch56]

We just fixed an old Drupal core issue where system certs/verify peer were not used for SSL requests. https://drupal.org/node/1081192

Guzzle supports this fine as an option, but I'm wondering why the default is to use the bundled certificates - opening this issue in case there's the option to change the default.

[klausi]

Quoting the comment from Drupal 8 core here:

Security consideration: we must not use the certificate authority file shipped with Guzzle because it can easily get outdated if a certificate authority is hacked. Instead, we rely on the certificate authority file provided by the operating system which is more likely going to be updated in a timely fashion.

I think the same applies to Guzzle, it should trust the operating system per default.

[mtdowling]

Guzzle has peer verification on by default and uses the provided CA bundle by default. This is done because most systems have outdated CA bundles and are unable to communicate over SSL without needing to manually download a CA bundle and modify their code to use it.

I don't understand how there is a claim that the CA bundle provided by Guzzle can be more easily out of date than the CA bundles packaged with distributions. I would argue that users of Guzzle can more easily update the Guzzle library than they could update a Linux package.

Using the bundled CA cert in Guzzle poses no security risk and provides the best experience for developers using Guzzle. If we didn't do this, then developers would likely just turn off verification because most people don't understand why it's important.

I've created an "if this then that" recipe that scans a feed from Mozilla for updates and automatically creates GitHub issues reminding me or another contributor to rebuild the bundled certificate. This will ensure that Guzzle's CA bundle is updated in a timely manner. http://hg.mozilla.org/mozilla-central/atom-log/aec6bf932306/security/nss/lib/ckfw/builtins/certdata.txt. If there's a better way to stay up to date on these, please let me know.

[klausi]

If you are on a crappy host then it makes sense to use some artificial CA bundle, for example the one shipped with Guzzle. If you are on a sane server setup then you should use the SSL CA file of the operating system.

Example scenario using the OS CA bundle: Debian has to create a packet release => Sysadmin has to deploy it.
Example scenario using the Guzzle CA bundle: Guzzle has to create a release => Drupal has to create a release => User has to deploy it.

So there is one more step involved as soon as Guzzle is used in another project. And usually Debian and Sysadmins deploy way faster than "end developers" or PHP library users. Updating an openssl package on Debian is a nobrainer, why would you think it is harder than updating Guzzle?

[mtdowling]

It's easier for users to update Guzzle than to update a package on all of their production servers, and I don't see how someone could honestly argue otherwise. Maybe this isn't the case for Drupal, but that isn't a concern of Guzzle and should not affect the default experience of Guzzle, which is why the default setting in Guzzle is the right thing to do. Bundling a CA bundle isn't uncommon either (e.g., https://github.com/kennethreitz/requests/blob/master/requests/cacert.pem).

A ton of PHP developers, including a large number of Drupal developers, don't have the ability to update the CA bundle on their system. Guzzle does the right thing by default while still allowing users to change the CA bundle used by Guzzle.

You can change the CA bundle used by Guzzle globally using a PHP ini setting as well: http://docs.guzzlephp.org/en/latest/clients.html#relevant-ini-settings

[klausi]

You will have to update all your production servers anyway, because SSL is probably used on all of them for something. But you are not done at that point: now you also have to update all your application code which includes Guzzle, if you are not using the system CA file.

I'm very happy that the CA file is configurable in Guzzle (great work!), so we could easily get this out of the way in Drupal. Still, using your own CA file is a very bad default setting - the default setting should be system.

[mtdowling]

I appreciate your input, but I don't think what you're proposing is the best thing to do for Guzzle users nor does what we're doing now pose a security risk. I'm going to close this issue as it isn't something that is going to change in Guzzle.

[mastacheata]

I don't want to start a discussion about the general problems of delegating trust to random companies and state agencies, so let's focus on the problem at hand.
Should the question really be about who updates their CA-bundle faster in the case of a compromitation?
Isn't it way more important to decide whom you trust more to not include malicious CAs in their bundle? Also for a project like Drupal isn't it much easier to decide on trusting @mtdowling (or not) as opposed to trusting a number of people at each distribution (relying on the distribution's CA-bundle means you trust all the maintainers of RHEL, CentOS, Fedora, Debian, Ubuntu, Gentoo and at least a dozen more, which makes this a group of around 100 people with independent meanings and decisions that you trust MORE than this single person or the community around his project)

[klausi]

That is not an either/or decision. Of course you already have to trust your OS vendor, since they distribute the most fundamental packages for your server. But you are not done at this point: now you also have to trust the Guzzle maintainer(s) that they know what they are doing when distributing SSL CA files. So while people are trusting 100 people for their servers already, they have to now trust 101 when using Guzzle's CA file.

The security principle of granting the least necessary privilege to make stuff work suggests to keep the number of people you have to trust as low as possible. This does not mean that we don't trust @mtdowling - we just don't want to trust him if we don't have to.

[mastacheata]

Touché, I didn't take the software side into account.
I just wanted to offer another perspective, not argue about any decisions anyways.
The real problem is at a more conceptual level (delegating trust to profit-oriented companies) and this is the wrong place to discuss that.

[mtdowling]

I got feedback on this issue from some sysadmins at work, and it turns out I was wrong on this one. Bundling a CA cert is not the right approach for Guzzle, and it is better to rely on the system's CA bundle. Thanks for opening the issue, and sorry it took so long for me to realize y'all were right.