Packaging crt bundle with the library

[bhelx]

A common problem merchants run into with this library is getting cert verification errors when connecting to Recurly because their bundles are out of date (or maybe not present?). This seems to be a common problem with libcurl. The general fix involves downloading a bundle from Mozilla on the merchant's server:

http://curl.haxx.se/docs/caextract.html

This is confusing and risky if the merchant is not fully aware of what they are doing. Also I'm not sure how they do this in a hosted environment. It seems to me that others who use php and libcurl have solved this problem by bundling the ca crt with the project

https://github.com/stripe/stripe-php/blob/738244c507bb1313c9bf24a7701d93bec37fa290/data/ca-certificates.crt

and referencing it specifically from the code:

https://github.com/stripe/stripe-php/blob/738244c507bb1313c9bf24a7701d93bec37fa290/lib/HttpClient/CurlClient.php#L141-144
https://github.com/stripe/stripe-php/blob/738244c507bb1313c9bf24a7701d93bec37fa290/lib/HttpClient/CurlClient.php#L90-92

Should we consider doing something like this?

\cc @drewish @csmb @reedox

[reedox]

The ideal situation (safest) would be for clients to keep their system certs up to date. This is usually done via a software upgrade (on debian/ubuntu the ca-certificates package provides the latest root certs).

It looks like stripe's client libraries are failing back to a local copy of certs provided in their repo when they get an SSL verification error. The risk with that method is if an attacker manages to overwrite the provided cert file on the file system (remote code execution or similar vuln), then they have free rein to use a self signed cert on their end and send connections over to their servers (maybe a credit card collecting proxy between them and us). This could all be done without the client errors so the user would never know. The system certs are usually better protected and only writable by the root user. Of course, if the user uses proper read-only permissions on the certs this isn't a problem. A way to mitigate this risk would be to make the fallback a configuration option we give to users if they have issues.

IMO while the risk is low, we should weigh this against the ability to just ask users to keep the certs / systems up to date (which they should be doing anyway).

[reedox]

Just a follow-up to my previous comment. It seems libcurl may use it's own certs instead of the system certs (on some older systems) which changes my opinion somewhat.

In that case, I don't think we have another option than to include the certs but this does slightly increase the risk to users with newer systems (for the same reasons I mentioned in my previous comments).

[bhelx]

Yeah, at the minimum I think we agree that there should be a config option

[bhelx]

Doing more investigation

[bhelx]

This was closed with #176