Request: Option for curl ssl verify peer

[richard4339]

Starting with curl 7.1, the curl setting CURLOPT_SSL_VERIFY_PEER is enabled by default along with curl opting to no longer provide a list of trusted CAs, meaning you cannot use curl for any SSL enabled website unless your administrator/host/etc. has realized this is an issue and set said options in the PHP configuration. The major shared hosting provided I use, for example, does not have this configured properly. This poses a problem since the entirety of this SDK is based around curl.

Assuming you can't simply "fix" the PHP configuration, there are a few ways to get around this, one of which is to set CURLOPT_SSL_VERIFY_PEER to false in ParseClient.php somewhere near line 336. Clearly this needs to be an option at most, not the default.

I'm happy to work on a pull request, but I wanted to gauge the opinions of the community and developers before working on it.

[montymxb]

Hmm, if you're in a scenario where you're missing trusted CAs you can indicate that curl should verify against those which you provide instead, for example:

// indicate the directory to search for the specific CA cert(s) needed
curl_setopt($ch, CURLOPT_CAPATH, "/path/to/your/cacert/dir/");

// or you can opt for a singular alternate cert to verify against
curl_setopt ($ch, CURLOPT_CAINFO, "/path/to/your/cacert.pem");

Either should work in your case assuming you have the appropriate CA cert(s), even if you're missing those CAs elsewhere. Just remember to reenable CURLOPT_SSL_VERIFYPEER first (you don't want to put yourself in the position of experiencing a potential MITM attack). I would try this and see if that works for you.

If you can't figure out how to work in the CA cert but still want to try a way to validate who you are connecting to you can try pinning the public key from your desired target's certificate. I've never tried it out myself, but in the absence of a proper CA cert to validate this would be the next best thing I can think of. There's a post about it here regarding (roughly) how to go about that.

We could use the ability to indicate alternative certs to verify against, and certificate pinning has been mentioned in #218 in the past. Assuming you try either of these methods and you succeed I would be open to a pull request that offered to pass additional config items into say ParseClient::initialize to alter the use of curl to handle these cases. You could indicate an alternate CA cert location and/or public key pinning, for example.

Let us know if this puts you in the right direction for solving your issue. Also it would be great if you would be willing to take your solution (assuming you find one) and propose a pull request so we can help anyone in the same predicament 👍 .

[richard4339]

Yeah @montymxb, I was going to offer some of those alternatives too. I'm glad to get your feedback on where to put the parameters, that was one of the main things I was questioning.

[montymxb]

Glad I could be of assistance in that regard! If you have any further questions about where and how to set this up feel free to ask. Whenever you can craft a pull request I'll go over that and we'll see if we can't get such a feature (or two) merged in.

[montymxb]

@richard4339 the sdk was recently updated to support independent transport layers. This added a curl & stream http client, both of which accept an alternative CA bundle file. You can see an example of this on the new README. This might be what you were looking for.

[montymxb]

Closing as the recent addition of transport layers supports adding an alt CA bundle file. Additionally an option to turn off peer verification will probably not be supported, given it's implications. For http this doesn't really change anything, but if you're opting for https and disabling peer verification you're not really getting the true benefits of TLS.

Although the alternative is to instead serve content over http on it's own this has known security implications. A big one being this allows others to modify the information in transit, modifying a request to potentially become malicious in nature.

If anyone still has any concerns or requests regarding ssl/tls verification issues, specifically regarding the curl options mentioned above, you can let me know and we will readdress this.

[parse-github-assistant]

The label type:feature cannot be used in combination with type:improvement.