Multiple issues related to SSL Interception (environs with proxy, enterprise MITM, etc)

Description

GitHub Desktop exhibits issues with authentication and repository cloning when SSL interception is present, such as Enterprise MITM configurations (Proxies and other cybersecurity products).

1. Logging into GitHub account via username and password within the GUI gives an error indicating the username and password is incorrect when they are correct. Logging in via browser still works. But error message is mis-leading and could trigger user interaction loops (reset password, try new password, reset it again, etc).

2. Cloning a repository throws cryptic errors about SChannel. Documented in #3326 I suspect this is at least partially related to interception, as switching to OpenSSL can still throw errors because of expected certificate signatures not matching.

3. Instructions for the workaround here are inconsistent and don’t seem to work. Do I use http.CAInfo, http.CAFile or http.CAPath? Do I specify the path in Windows notation (C:\foo\bar) or the Git bash shell form (/c/foo/bar)? Regardless of what I set, I could not get this solution to work. Instead, I had to issue a “git config --global http.sslVerify false” so I could use the openSSL backend and get around the problems with accessing the cert file.

4. Only that didn’t actually work. Because now I get “fatal: .git/index: index file open failed: Permission denied”. Or hey maybe it did, the files are there. But I just wasted 1.5 hours on this.

Version

• GitHub Desktop: 1.1.0

• Operating system: Microsoft Windows 10.0.14393

Steps to Reproduce

Reproduction would require access to a restricted corporate environment. Recommend setting up a lab and configuring an Enterprise grade security product such as BlueCoat or similar that does MITM, then using internal certificates for the pass-back.

Expected Behavior

1. Sign-in directly with no error, or get a message indicating issues communicating with auth server.

2. Clone the repo without any hassle.

3. Should never get here but if we do, shouldn’t have confusing workarounds that don’t work.

Actual Behavior

Augh. See above. I’m hating this form now.

Additional Information

Logs

2018-03-06.desktop.production.log

[shiftkey]

@DeepMac thanks for the detailed report! You’ve encountered a known issue which, as you mention, is related to SSL interception:

Cloning into 'C:\Users\jmercer1\Documents\GitHub\apache-log-parser'...
fatal: unable to access 'https://github.com/rory/apache-log-parser.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.

This is occurring because our embedded Git is using SChannel - which relies on the Windows Certificate Store - for doing SSL/TLS handshaking. On some networks, the revocation checks are blocked, and so Git fails the clone. It’s hard for us to detect this behaviour without actually performing a clone or fetch/push/pull.

This has been documented as a known issue - the workaround documented will switch you back to the classic OpenSSL-based certificate checks and avoid this issue.

I’ve submitted a config flag to Git for Windows https://github.com/git-for-windows/git/pull/1450 to support bypassing the revocation check on SChannel - there’s an open issue that I need to investigate to confirm this works as expected: https://github.com/git-for-windows/git/issues/1531

Once I’m confident in this new behaviour, and we update our embedded Git, I’ll revisit #3326 which is improving this experience in Desktop.

[steveward]

We’ve made improvements to proxy support and schannel (https://github.com/desktop/desktop/pull/10581), so I’m going to close this out.