[RFC] new config value to ignore revocation checks when using schannel

[shiftkey]

In GitHub Desktop we set http.sslBackend to schannel in the system gitconfig, which means everything Just Works™ for people who have certificates for their corporate Git servers in their Windows Certificate Store.

But some of these users are also behind a corporate firewall, which means they'll see a cryptic error like this:

fatal: unable to access 'https://some-server-address/user/repo.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) - The revocation function was unable to check revocation because the revocation server was offline.

There's a couple of different variants here, and I can dig them up later for completeness. But the theme is the same - the revocation check now fails, and so the user cannot connect to the remote repository.

I've always had reservations about weakening the SSL/TLS handshaking process between the server and client, but after talking more with various users this seems like an unavoidable fact of life for some.

Two interesting notes about this:

• according to this report IE suppresses this error and let's the user continue on with connecting to the server - and enabling a registry value makes IE surface this error

• the Rust community went through this exact process with libcurl in "SSL connect error" on Windows rust-lang/cargo#2464 and ended up adding a config value named http.check-revoke which is a boolean flag to bypass these checks (opt-in).

So what I'm proposing (I'll put together the patches) is adding support for a new config value which will be passed to curl to suppress these revocation checks.

This mailing list thread which suggests this is already supported:

If you are unable to find the cause and your circumstances allow you can
disable revocation checking per session in curl w/ WinSSL by using
option --ssl-no-revoke [1] in curl >= 7.44 or by passing flag
CURLSSLOPT_NO_REVOKE to CURLOPT_SSL_OPTIONS [2] in libcurl >= 7.44.

I think this should only be applied when http.sslBackend is schannel, as the openssl backend doesn't seem to suffer from this defect.

As to the configuration value - what about something like http.sslNoRevoke? This is close to the underlying libcurl value, but might be a bit unclear.

I also don't quite have the right setup to test this behaviour, so I'll ask around for help with validating from the reports I've seen, but if others are familiar with this issue I'd love their help with reviewing.

[Acetylen3]

Hi, I'm not expert in networking but I have just started using GitHub Desktop with AWS CodeCommit under corporate proxy. GitHub Desktop also gives Unknown error (0x80092013) when try to fetch from remote repo on AWS.

However, when I try to fetch from repo in command line (cmd), it work just fine. I suspect this is because Git credential helper was replaced by the AWS credential profile (may be it used openssl under the hood, I don't know) during installation of AWS CLI.

I don't know if my issue is same as this one, but I'm surprise to see different behavior using git in cmd vs GitHub Desktop, I always think GitHub Desktop is essentially a GUI wrap around of the same git core. If this is the same issue, I will wait for your patch.

[j-f1]

How about http.disableRevocationChecks?

[dscho]

@shiftkey makes tons of sense. But since you want this for schannel only, why not call the setting http.schannel.checkRevoke (defaulting to true) and really only handling it when the ssl backend was set explicitly to schannel?

[shiftkey]

@dscho sure, I can go for that

[shiftkey]

@Acetylen3

However, when I try to fetch from repo in command line (cmd), it work just fine. I suspect this is because Git credential helper was replaced by the AWS credential profile (may be it used openssl under the hood, I don't know) during installation of AWS CLI.

I don't believe it's related to the credential provider, but to the configured http.sslBackend that Git uses for all fetch/push/pull operations. You can run this on the command line and see what it has configured:

$ git config http.sslBackend

If nothing is returned, you're using the classic openssl behaviour. GitHub Desktop switched over to using the new schannel backend back in August 2017.

[Acetylen3]

@shiftkey Hi, you're right, it has nothing to do with credential provider but ssl backend, everything works after I use config:

git config --global http.sslBackend "openssl"

Thank you for your help.