Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
changed behavior of CURLOPT_SSL_VERIFYPEER + CURLOPT_CAINFO_BLOB (libcurl 7.87.0)
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Paul Groke via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 27 Jan 2023 10:13:00 +0100
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
Date: Fri, 27 Jan 2023 10:13:00 +0100
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.htmlReceived on 2023-01-27