Navigation Menu

Skip to content

Commit

Permalink
http: use new "best effort" strategy for Secure Channel revoke checking
Browse files Browse the repository at this point in the history
The native Windows HTTPS backend is based on Secure Channel which lets
the caller decide how to handle revocation checking problems caused by
missing information in the certificate or offline CRL distribution
points.

Unfortunately, cURL chose to handle these problems differently than
OpenSSL by default: while OpenSSL happily ignores those problems
(essentially saying "¯\_(ツ)_/¯"), the Secure Channel backend will error
out instead.

As a remedy, the "no revoke" mode was introduced, which turns off
revocation checking altogether. This is a bit heavy-handed. We support
this via the `http.schannelCheckRevoke` setting.

In curl/curl#4981, we contributed an opt-in
"best effort" strategy that emulates what OpenSSL seems to do.

In Git for Windows, we actually want this to be the default. This patch
makes it so, introducing it as a new value for the
`http.schannelCheckRevoke" setting, which now becmes a tristate: it
accepts the values "false", "true" or "best-effort" (defaulting to the
last one).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
  • Loading branch information
dscho committed May 15, 2020
1 parent 80636a9 commit 7fdfc1b
Show file tree
Hide file tree
Showing 2 changed files with 29 additions and 9 deletions.
12 changes: 7 additions & 5 deletions Documentation/config/http.txt
Expand Up @@ -173,11 +173,13 @@ http.sslBackend::

http.schannelCheckRevoke::
Used to enforce or disable certificate revocation checks in cURL
when http.sslBackend is set to "schannel". Defaults to `true` if
unset. Only necessary to disable this if Git consistently errors
and the message is about checking the revocation status of a
certificate. This option is ignored if cURL lacks support for
setting the relevant SSL option at runtime.
when http.sslBackend is set to "schannel" via "true" and "false",
respectively. Another accepted value is "best-effort" (the default)
in which case revocation checks are performed, but errors due to
revocation list distribution points that are offline are silently
ignored, as well as errors due to certificates missing revocation
list distribution points. This option is ignored if cURL lacks
support for setting the relevant SSL option at runtime.

http.schannelUseSSLCAInfo::
As of cURL v7.60.0, the Secure Channel backend can use the
Expand Down
26 changes: 22 additions & 4 deletions http.c
Expand Up @@ -165,7 +165,13 @@ static char *cached_accept_language;

static char *http_ssl_backend;

static int http_schannel_check_revoke = 1;
static int http_schannel_check_revoke_mode =
#ifdef CURLSSLOPT_REVOKE_BEST_EFFORT
CURLSSLOPT_REVOKE_BEST_EFFORT;
#else
CURLSSLOPT_NO_REVOKE;
#endif

/*
* With the backend being set to `schannel`, setting sslCAinfo would override
* the Certificate Store in cURL v7.60.0 and later, which is not what we want
Expand Down Expand Up @@ -330,7 +336,19 @@ static int http_options(const char *var, const char *value, void *cb)
}

if (!strcmp("http.schannelcheckrevoke", var)) {
http_schannel_check_revoke = git_config_bool(var, value);
if (value && !strcmp(value, "best-effort")) {
http_schannel_check_revoke_mode =
#ifdef CURLSSLOPT_REVOKE_BEST_EFFORT
CURLSSLOPT_REVOKE_BEST_EFFORT;
#else
CURLSSLOPT_NO_REVOKE;
warning(_("%s=%s unsupported by current cURL"),
var, value);
#endif
} else
http_schannel_check_revoke_mode =
(git_config_bool(var, value) ?
0 : CURLSSLOPT_NO_REVOKE);
return 0;
}

Expand Down Expand Up @@ -913,9 +931,9 @@ static CURL *get_curl_handle(void)
#endif

if (http_ssl_backend && !strcmp("schannel", http_ssl_backend) &&
!http_schannel_check_revoke) {
http_schannel_check_revoke_mode) {
#if LIBCURL_VERSION_NUM >= 0x072c00
curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE);
curl_easy_setopt(result, CURLOPT_SSL_OPTIONS, http_schannel_check_revoke_mode);
#else
warning(_("CURLSSLOPT_NO_REVOKE not supported with cURL < 7.44.0"));
#endif
Expand Down

0 comments on commit 7fdfc1b

Please sign in to comment.