2024-01-17 18:32:44 +08:00
|
|
|
---
|
2024-02-28 18:28:10 +08:00
|
|
|
c: Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
2024-01-17 18:32:44 +08:00
|
|
|
SPDX-License-Identifier: curl
|
|
|
|
Title: CURLOPT_PROXY_SSL_OPTIONS
|
|
|
|
Section: 3
|
|
|
|
Source: libcurl
|
|
|
|
See-also:
|
|
|
|
- CURLOPT_PROXY_SSLVERSION (3)
|
|
|
|
- CURLOPT_PROXY_SSL_CIPHER_LIST (3)
|
|
|
|
- CURLOPT_SSLVERSION (3)
|
|
|
|
- CURLOPT_SSL_CIPHER_LIST (3)
|
2024-03-21 18:50:20 +08:00
|
|
|
Protocol:
|
|
|
|
- TLS
|
2024-03-21 22:46:32 +08:00
|
|
|
TLS-backend:
|
|
|
|
- All
|
2024-07-18 06:51:50 +08:00
|
|
|
Added-in: 7.52.0
|
2024-01-17 18:32:44 +08:00
|
|
|
---
|
|
|
|
|
|
|
|
# NAME
|
|
|
|
|
|
|
|
CURLOPT_PROXY_SSL_OPTIONS - HTTPS proxy SSL behavior options
|
|
|
|
|
|
|
|
# SYNOPSIS
|
|
|
|
|
|
|
|
~~~c
|
2016-11-17 01:49:15 +08:00
|
|
|
#include <curl/curl.h>
|
|
|
|
|
2021-11-26 21:20:18 +08:00
|
|
|
CURLcode curl_easy_setopt(CURL *handle, CURLOPT_PROXY_SSL_OPTIONS,
|
|
|
|
long bitmask);
|
2024-01-17 18:32:44 +08:00
|
|
|
~~~
|
|
|
|
|
|
|
|
# DESCRIPTION
|
|
|
|
|
2020-01-23 15:51:52 +08:00
|
|
|
Pass a long with a bitmask to tell libcurl about specific SSL
|
|
|
|
behaviors. Available bits:
|
2024-01-17 18:32:44 +08:00
|
|
|
|
|
|
|
## CURLSSLOPT_ALLOW_BEAST
|
|
|
|
|
2020-01-23 15:51:52 +08:00
|
|
|
Tells libcurl to not attempt to use any workarounds for a security flaw in the
|
2024-01-17 18:32:44 +08:00
|
|
|
SSL3 and TLS1.0 protocols. If this option is not used or this bit is set to 0,
|
2023-08-02 14:06:03 +08:00
|
|
|
the SSL layer libcurl uses may use a work-around for this flaw although it
|
2023-07-30 05:44:28 +08:00
|
|
|
might cause interoperability problems with some (older) SSL implementations.
|
|
|
|
WARNING: avoiding this work-around lessens the security, and by setting this
|
2024-01-17 18:32:44 +08:00
|
|
|
option to 1 you ask for exactly that. This option is only supported for Secure
|
|
|
|
Transport and OpenSSL.
|
|
|
|
|
|
|
|
## CURLSSLOPT_NO_REVOKE
|
|
|
|
|
2020-01-23 15:51:52 +08:00
|
|
|
Tells libcurl to disable certificate revocation checks for those SSL backends
|
|
|
|
where such behavior is present. This option is only supported for Schannel
|
|
|
|
(the native Windows SSL library), with an exception in the case of Windows'
|
2021-10-31 23:34:44 +08:00
|
|
|
Untrusted Publishers block list which it seems cannot be bypassed. (Added in
|
2020-01-23 15:51:52 +08:00
|
|
|
7.44.0)
|
2024-01-17 18:32:44 +08:00
|
|
|
|
|
|
|
## CURLSSLOPT_NO_PARTIALCHAIN
|
|
|
|
|
2020-01-23 15:51:52 +08:00
|
|
|
Tells libcurl to not accept "partial" certificate chains, which it otherwise
|
2023-08-22 23:40:39 +08:00
|
|
|
does by default. This option is only supported for OpenSSL and fails the
|
2020-01-23 15:51:52 +08:00
|
|
|
certificate verification if the chain ends with an intermediate certificate
|
|
|
|
and not with a root cert. (Added in 7.68.0)
|
2024-01-17 18:32:44 +08:00
|
|
|
|
|
|
|
## CURLSSLOPT_REVOKE_BEST_EFFORT
|
|
|
|
|
schannel: add "best effort" revocation check option
- Implement new option CURLSSLOPT_REVOKE_BEST_EFFORT and
--ssl-revoke-best-effort to allow a "best effort" revocation check.
A best effort revocation check ignores errors that the revocation check
was unable to take place. The reasoning is described in detail below and
discussed further in the PR.
---
When running e.g. with Fiddler, the schannel backend fails with an
unhelpful error message:
Unknown error (0x80092012) - The revocation function was unable
to check revocation for the certificate.
Sadly, many enterprise users who are stuck behind MITM proxies suffer
the very same problem.
This has been discussed in plenty of issues:
https://github.com/curl/curl/issues/3727,
https://github.com/curl/curl/issues/264, for example.
In the latter, a Microsoft Edge developer even made the case that the
common behavior is to ignore issues when a certificate has no recorded
distribution point for revocation lists, or when the server is offline.
This is also known as "best effort" strategy and addresses the Fiddler
issue.
Unfortunately, this strategy was not chosen as the default for schannel
(and is therefore a backend-specific behavior: OpenSSL seems to happily
ignore the offline servers and missing distribution points).
To maintain backward-compatibility, we therefore add a new flag
(`CURLSSLOPT_REVOKE_BEST_EFFORT`) and a new option
(`--ssl-revoke-best-effort`) to select the new behavior.
Due to the many related issues Git for Windows and GitHub Desktop, the
plan is to make this behavior the default in these software packages.
The test 2070 was added to verify this behavior, adapted from 310.
Based-on-work-by: georgeok <giorgos.n.oikonomou@gmail.com>
Co-authored-by: Markus Olsson <j.markus.olsson@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Closes https://github.com/curl/curl/pull/4981
2020-02-26 18:24:26 +08:00
|
|
|
Tells libcurl to ignore certificate revocation checks in case of missing or
|
|
|
|
offline distribution points for those SSL backends where such behavior is
|
|
|
|
present. This option is only supported for Schannel (the native Windows SSL
|
2024-01-17 18:32:44 +08:00
|
|
|
library). If combined with *CURLSSLOPT_NO_REVOKE*, the latter takes
|
schannel: add "best effort" revocation check option
- Implement new option CURLSSLOPT_REVOKE_BEST_EFFORT and
--ssl-revoke-best-effort to allow a "best effort" revocation check.
A best effort revocation check ignores errors that the revocation check
was unable to take place. The reasoning is described in detail below and
discussed further in the PR.
---
When running e.g. with Fiddler, the schannel backend fails with an
unhelpful error message:
Unknown error (0x80092012) - The revocation function was unable
to check revocation for the certificate.
Sadly, many enterprise users who are stuck behind MITM proxies suffer
the very same problem.
This has been discussed in plenty of issues:
https://github.com/curl/curl/issues/3727,
https://github.com/curl/curl/issues/264, for example.
In the latter, a Microsoft Edge developer even made the case that the
common behavior is to ignore issues when a certificate has no recorded
distribution point for revocation lists, or when the server is offline.
This is also known as "best effort" strategy and addresses the Fiddler
issue.
Unfortunately, this strategy was not chosen as the default for schannel
(and is therefore a backend-specific behavior: OpenSSL seems to happily
ignore the offline servers and missing distribution points).
To maintain backward-compatibility, we therefore add a new flag
(`CURLSSLOPT_REVOKE_BEST_EFFORT`) and a new option
(`--ssl-revoke-best-effort`) to select the new behavior.
Due to the many related issues Git for Windows and GitHub Desktop, the
plan is to make this behavior the default in these software packages.
The test 2070 was added to verify this behavior, adapted from 310.
Based-on-work-by: georgeok <giorgos.n.oikonomou@gmail.com>
Co-authored-by: Markus Olsson <j.markus.olsson@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Closes https://github.com/curl/curl/pull/4981
2020-02-26 18:24:26 +08:00
|
|
|
precedence. (Added in 7.70.0)
|
2024-01-17 18:32:44 +08:00
|
|
|
|
|
|
|
## CURLSSLOPT_NATIVE_CA
|
|
|
|
|
2023-01-06 07:32:27 +08:00
|
|
|
Tell libcurl to use the operating system's native CA store for certificate
|
2023-10-16 20:46:36 +08:00
|
|
|
verification. If you set this option and also set a CA certificate file or
|
|
|
|
directory then during verification those certificates are searched in addition
|
|
|
|
to the native CA store.
|
|
|
|
|
|
|
|
Works with wolfSSL on Windows, Linux (Debian, Ubuntu, Gentoo, Fedora, RHEL),
|
|
|
|
macOS, Android and iOS (added in 8.3.0), with GnuTLS (added in 8.5.0) or on
|
|
|
|
Windows when built to use OpenSSL (Added in 7.71.0).
|
2024-01-17 18:32:44 +08:00
|
|
|
|
|
|
|
## CURLSSLOPT_AUTO_CLIENT_CERT
|
|
|
|
|
2021-02-28 05:27:31 +08:00
|
|
|
Tell libcurl to automatically locate and use a client certificate for
|
|
|
|
authentication, when requested by the server. This option is only supported
|
|
|
|
for Schannel (the native Windows SSL library). Prior to 7.77.0 this was the
|
|
|
|
default behavior in libcurl with Schannel. Since the server can request any
|
|
|
|
certificate that supports client authentication in the OS certificate store it
|
|
|
|
could be a privacy violation and unexpected.
|
|
|
|
(Added in 7.77.0)
|
2024-01-17 18:32:44 +08:00
|
|
|
|
|
|
|
# DEFAULT
|
|
|
|
|
2016-11-17 01:49:15 +08:00
|
|
|
0
|
2024-01-17 18:32:44 +08:00
|
|
|
|
2024-07-19 07:06:06 +08:00
|
|
|
# %PROTOCOLS%
|
|
|
|
|
2024-01-17 18:32:44 +08:00
|
|
|
# EXAMPLE
|
|
|
|
|
|
|
|
~~~c
|
2023-12-04 17:50:42 +08:00
|
|
|
int main(void)
|
|
|
|
{
|
|
|
|
CURL *curl = curl_easy_init();
|
|
|
|
if(curl) {
|
|
|
|
CURLcode res;
|
|
|
|
curl_easy_setopt(curl, CURLOPT_URL, "https://example.com/");
|
|
|
|
curl_easy_setopt(curl, CURLOPT_PROXY, "https://proxy");
|
|
|
|
/* weaken TLS only for use with silly proxies */
|
|
|
|
curl_easy_setopt(curl, CURLOPT_PROXY_SSL_OPTIONS, CURLSSLOPT_ALLOW_BEAST |
|
|
|
|
CURLSSLOPT_NO_REVOKE);
|
|
|
|
res = curl_easy_perform(curl);
|
|
|
|
curl_easy_cleanup(curl);
|
|
|
|
}
|
2017-05-31 17:56:28 +08:00
|
|
|
}
|
2024-01-17 18:32:44 +08:00
|
|
|
~~~
|
|
|
|
|
2024-07-19 07:06:06 +08:00
|
|
|
# %AVAILABILITY%
|
|
|
|
|
2024-01-17 18:32:44 +08:00
|
|
|
# RETURN VALUE
|
|
|
|
|
2016-11-17 01:49:15 +08:00
|
|
|
Returns CURLE_OK if the option is supported, and CURLE_UNKNOWN_OPTION if not.
|