Re: changed behavior of CURLOPT_SSL_VERIFYPEER + CURLOPT_CAINFO_BLOB (libcurl 7.87.0)
On Fri, 27 Jan 2023, Ray Satiro via curl-library wrote: Since CURLOPT_CAINFO_BLOB is documented as "one or more certificates" [1] I don't think this is a bug however I've opened an issue [2] for further discussion. [2]: https://github.com/curl/curl/issues/10351 I've proposed a very small change to bring back the old behavior and support "blank" blobs: https://github.com/curl/curl/pull/10359 We should then probably also document that CURLOPT_CAINFO_BLOB can in fact also be used for *no* certs. -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: changed behavior of CURLOPT_SSL_VERIFYPEER + CURLOPT_CAINFO_BLOB (libcurl 7.87.0)
On 1/27/2023 4:13 AM, Paul Groke via curl-library wrote: we noticed a change in behavior wrt. CURLOPT_SSL_VERIFYPEER and CURLOPT_CAINFO_BLOB with libcurl 7.87.0. Our application always sets CURLOPT_CAINFO_BLOB to a non-null value, because we never want to use any built-in default/system default certificate bundle path. If no CAs are configured for our software, we set CURLOPT_CAINFO_BLOB with a non-null pointer to a `curl_blob` struct, which has `len` set to zero (and `data` pointing to a null byte). Additionally we set CURLOPT_SSL_VERIFYPEER to whatever our appliaction's config requests. We often have the case where CURLOPT_CAINFO_BLOB is set to "empty string" as described above, and CURLOPT_SSL_VERIFYPEER is set to 0. With previous libcurl versions, this used to work. Which to me makes sense. We explicitly instruct libcurl to use an empty certificate list, but also tell it to not verify certificates. So IMO there's no reason for a transfer with such settings to fail because of a certificate-related error. With 7.87.0, the behavior changed: the transfer now fails with error Problem with the SSL CA cert (path? access rights?). We link libcurl statically and have tests that cover this combination, so at least for us this didn't break any existing installations. For new versions, we can work around it by changing our code to clear/reset CURLOPT_CAINFO_BLOB by setting a null pointer in case our verify peer option is set to "false". I still thought I should let you know, because this looks like an unintended and also undesirable change to me. It could break applications with similar usage of CURLOPT_CAINFO_BLOB + CURLOPT_SSL_VERIFYPEER, if they link libcurl dynamically or don't have tests that cover this combination. My guess is that this was caused by the new certificate caching code, but we didn't verify this hypothesis. Another thing that may be worth checking is setting CURLOPT_CAINFO or CURLOPT_CAPATH to a non-existing path/"permission denied" path, while also setting CURLOPT_SSL_VERIFYPEER=0. I wouldn't be surprised if this also results in the same error. And if memory serves, this also used to work. I think you're right that this change is due to the added certificate caching support for the OpenSSL backend that preceded 7.87.0. Since CURLOPT_CAINFO_BLOB is documented as "one or more certificates" [1] I don't think this is a bug however I've opened an issue [2] for further discussion. [1]: https://curl.se/libcurl/c/CURLOPT_CAINFO_BLOB.html [2]: https://github.com/curl/curl/issues/10351 -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: changed behavior of CURLOPT_SSL_VERIFYPEER + CURLOPT_CAINFO_BLOB (libcurl 7.87.0)
Hi Paul, I may have accidentally killed that while refactoring the TLS backend IO handling. Sorry about that. I think we need a test case for that edge case. Kind Regards, Stefan > Am 27.01.2023 um 10:13 schrieb Paul Groke via curl-library > : > > Hi, > > we noticed a change in behavior wrt. CURLOPT_SSL_VERIFYPEER and > CURLOPT_CAINFO_BLOB with libcurl 7.87.0. > > Our application always sets CURLOPT_CAINFO_BLOB to a non-null value, because > we never want to use any built-in default/system default certificate bundle > path. > If no CAs are configured for our software, we set CURLOPT_CAINFO_BLOB with a > non-null pointer to a `curl_blob` struct, which has `len` set to zero (and > `data` pointing to a null byte). > Additionally we set CURLOPT_SSL_VERIFYPEER to whatever our appliaction's > config requests. > > We often have the case where CURLOPT_CAINFO_BLOB is set to "empty string" as > described above, and CURLOPT_SSL_VERIFYPEER is set to 0. > > With previous libcurl versions, this used to work. Which to me makes sense. > We explicitly instruct libcurl to use an empty certificate list, but also > tell it to not verify certificates. So IMO there's no reason for a transfer > with such settings to fail because of a certificate-related error. > > With 7.87.0, the behavior changed: the transfer now fails with error > >> Problem with the SSL CA cert (path? access rights?). > > We link libcurl statically and have tests that cover this combination, so at > least for us this didn't break any existing installations. For new versions, > we can work around it by changing our code to clear/reset CURLOPT_CAINFO_BLOB > by setting a null pointer in case our verify peer option is set to "false". > > I still thought I should let you know, because this looks like an unintended > and also undesirable change to me. It could break applications with similar > usage of CURLOPT_CAINFO_BLOB + CURLOPT_SSL_VERIFYPEER, if they link libcurl > dynamically or don't have tests that cover this combination. > > My guess is that this was caused by the new certificate caching code, but we > didn't verify this hypothesis. > > Another thing that may be worth checking is setting CURLOPT_CAINFO or > CURLOPT_CAPATH to a non-existing path/"permission denied" path, while also > setting CURLOPT_SSL_VERIFYPEER=0. I wouldn't be surprised if this also > results in the same error. And if memory serves, this also used to work. > > Best regards, > Paul > -- > Unsubscribe: https://lists.haxx.se/listinfo/curl-library > Etiquette: https://curl.se/mail/etiquette.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
