Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

[Johan Laenen]

Commit 5841520b makes it impossible to connect to github from behind my
company's firewall.

I'm running CYGWIN_NT-6.1 and the default git version 2.5.3 complains with a
fatal error when trying to git pull:

$ /bin/git --version
git version 2.5.3
$ /bin/git pull
fatal: unable to access 'https://github.com/gargle/french/': Unknown SSL
protocol error in connection to github.com:443

Taking the sources of git 2.6.1. and compiling with commit 5841520b in
http.c reverted gives me a working git.

My http.c now looks like:

 466     if (curl_http_proxy) {
 467         curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
 468 #if LIBCURL_VERSION_NUM >= 0x070a07
 469         curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
 470 #endif
 471     }

And it works:

$ git --version
git version 2.6.1
$ git pull
Already up-to-date.



Greetings,

Johan

Re: Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

[Matthieu Moy]

Hi,

I'm just Cc-ing Enrique, the author of 5841520b.

Johan Laenen <johan.laenen+cygwin@gmail.com> writes:

> Commit 5841520b makes it impossible to connect to github from behind my
> company's firewall.
>
> I'm running CYGWIN_NT-6.1 and the default git version 2.5.3 complains with a
> fatal error when trying to git pull:
>
> $ /bin/git --version
> git version 2.5.3
> $ /bin/git pull
> fatal: unable to access 'https://github.com/gargle/french/': Unknown SSL
> protocol error in connection to github.com:443
>
> Taking the sources of git 2.6.1. and compiling with commit 5841520b in
> http.c reverted gives me a working git.
>
> My http.c now looks like:
>
>  466     if (curl_http_proxy) {
>  467         curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
>  468 #if LIBCURL_VERSION_NUM >= 0x070a07
>  469         curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
>  470 #endif
>  471     }
>
> And it works:
>
> $ git --version
> git version 2.6.1
> $ git pull
> Already up-to-date.
>
>
>
> Greetings,
>
> Johan

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

RE: Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

[Enrique Tobis]

Hey!

I'm really sorry to hear that.

That change should enable more forms of authentication with your proxy, but it does cause libcurl to choose the one it finds most secure, according to the docs (http://curl.haxx.se/libcurl/c/CURLOPT_HTTPAUTH.html) What kinds of authentication does your proxy use?

Thanks,
Enrique

-----Original Message-----
From: Matthieu Moy [mailto:Matthieu.Moy@grenoble-inp.fr] 
Sent: Tuesday, October 20, 2015 07:46
To: Johan Laenen
Cc: git@vger.kernel.org; Enrique Tobis
Subject: Re: Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

Hi,

I'm just Cc-ing Enrique, the author of 5841520b.

Johan Laenen <johan.laenen+cygwin@gmail.com> writes:

> Commit 5841520b makes it impossible to connect to github from behind my
> company's firewall.
>
> I'm running CYGWIN_NT-6.1 and the default git version 2.5.3 complains with a
> fatal error when trying to git pull:
>
> $ /bin/git --version
> git version 2.5.3
> $ /bin/git pull
> fatal: unable to access 'https://github.com/gargle/french/': Unknown SSL
> protocol error in connection to github.com:443
>
> Taking the sources of git 2.6.1. and compiling with commit 5841520b in
> http.c reverted gives me a working git.
>
> My http.c now looks like:
>
>  466     if (curl_http_proxy) {
>  467         curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
>  468 #if LIBCURL_VERSION_NUM >= 0x070a07
>  469         curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
>  470 #endif
>  471     }
>
> And it works:
>
> $ git --version
> git version 2.6.1
> $ git pull
> Already up-to-date.
>
>
>
> Greetings,
>
> Johan

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

[Johan Laenen]

Enrique Tobis <Enrique.Tobis <at> twosigma.com> writes:

> 
> Hey!
> 
> I'm really sorry to hear that.
> 
> That change should enable more forms of authentication with your proxy,
but it does cause libcurl to choose
> the one it finds most secure, according to the docs
> (http://curl.haxx.se/libcurl/c/CURLOPT_HTTPAUTH.html) What kinds of
authentication does your
> proxy use?
> 
> Thanks,
> Enrique
> 

Hi,

Thanks for looking into this.

I'm behind a NTLM proxy :/

Greetings,

Johan

Re: Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

[Johan Laenen]

Johan Laenen <johan.laenen+cygwin <at> gmail.com> writes:

I'm not the only one. Another cygwin user is experiencing the exact same
problem, see http://permalink.gmane.org/gmane.os.cygwin/155039 for more info.

greetings,

Johan

Re: Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

[Junio C Hamano]

Enrique Tobis <Enrique.Tobis@twosigma.com> writes:

> Hey!
>
> I'm really sorry to hear that.
>
> That change should enable more forms of authentication with your
> proxy, but it does cause libcurl to choose the one it finds most
> secure, according to the docs
> (http://curl.haxx.se/libcurl/c/CURLOPT_HTTPAUTH.html) What kinds of
> authentication does your proxy use?

Good line of thought.  The answer would reveal what non-working
authentication form the proxy claims to support is chosen because
libcurl considers more secure than the one the user wants to use.
I'd imagine that the next step after that would be to make the list
of authentication forms configurable so that the user can say "hey
my proxy claims to support this one but it does not work" to skip
it?

That sounds like a similar approach as what we did for SSL ciphers
in f6f2a9e4 (http: add support for specifying an SSL cipher list,
2015-05-08) where some people had problems with certain cipher the
server/client claimed to support when it was in fact broken.

Thanks.

RE: Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

[Enrique Tobis]

From: Junio C Hamano [mailto:jch2355@gmail.com] On Behalf Of Junio C Hamano

> Enrique Tobis <Enrique.Tobis@twosigma.com> writes:

>> Hey!
>>
>> I'm really sorry to hear that.
>>
>> That change should enable more forms of authentication with your 
>> proxy, but it does cause libcurl to choose the one it finds most 
>> secure, according to the docs
>> (http://curl.haxx.se/libcurl/c/CURLOPT_HTTPAUTH.html) What kinds of 
>> authentication does your proxy use?

> Good line of thought.  The answer would reveal what non-working authentication form the proxy claims to support is chosen because libcurl considers  more secure than the one the user wants to use.
> I'd imagine that the next step after that would be to make the list of authentication forms configurable so that the user can say "hey my proxy claims to support this one but it does not work" to skip it?

> That sounds like a similar approach as what we did for SSL ciphers in f6f2a9e4 (http: add support for specifying an SSL cipher list,
2015-05-08) where some people had problems with certain cipher the server/client claimed to support when it was in fact broken.

> Thanks.

@Junio: I agree. From the post in the cygwin mailing list that Johan mentioned, the problem seems to be that the proxy supports NEGOTIATE, NTLM and Basic, and libcurl is choosing NEGOTIATE. That choice fails for that user.

There is something I don't understand, though. Johan must be configuring his proxy either a) through git config files; or b) through environment variables. Johan says his proxy uses NTLM authentication. If he is doing a), then my change should not have had any impact. We were already setting CURLOPT_PROXYAUTH to CURLAUTH_ANY in that case. If it's b), then his proxy couldn't have been using NTLM authentication. In the old code path, only _BASIC was available as an authentication mechanism. That default is what prompted me to make the change in the first place.

@Johan: how are you configuring your proxy? Git configuration or environment variables? Also, could you run GIT_CURL_VERBOSE=1 git pull and send the output. That should show the failing authentication method.

Thanks.

Re: Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

[Johan Laenen]

Enrique Tobis <Enrique.Tobis <at> twosigma.com> writes:

>  <at> Johan: how are you configuring your proxy? Git configuration or
environment variables? Also, could you


I'm just using the https_proxy environment variable, not the git configuration:

$ export https_proxy=http://<userid>:<pw>@myproxy:8080



Sorry for the multiple attemps at answering your questions, but the mailing
list keeps on complaining about spam :/

Re: Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

[Johan Laenen]

[-- Attachment #1: Type: text/plain, Size: 221 bytes --]

Enrique Tobis <Enrique.Tobis <at> twosigma.com> writes:

> run GIT_CURL_VERBOSE=1 git pull and send the output. That should show the failing authentication method.



Please see the file in attachment,

greetings,

Johan

[-- Attachment #2: git.txt --]
[-- Type: text/plain, Size: 2728 bytes --]

$ GIT_CURL_VERBOSE=1 /bin/git pull
* STATE: INIT => CONNECT handle 0x20081bd0; line 1090 (connection #-5000)
* Couldn't find host github.com in the .netrc file; using defaults
* Added connection 0. The cache now contains 1 members
*   Trying 10.192.45.149...
* STATE: CONNECT => WAITCONNECT handle 0x20081bd0; line 1143 (connection #0)
* Connected to myproxy (10.192.45.149) port 8080 (#0)
* STATE: WAITCONNECT => WAITPROXYCONNECT handle 0x20081bd0; line 1240 (connection #0)
* Establish HTTP proxy tunnel to github.com:443
> CONNECT github.com:443 HTTP/1.1
Host: github.com:443
User-Agent: git/2.5.3
Proxy-Connection: Keep-Alive

* Read response immediately from proxy CONNECT
< HTTP/1.1 407 Proxy Authentication Required
< Proxy-Authenticate: NEGOTIATE
< Proxy-Authenticate: NTLM
< Proxy-Authenticate: BASIC realm="POST_AD"
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Proxy-Connection: close
< Connection: close
< Content-Length: 1025
<
* Ignore 1025 bytes of response-body
* Connect me again please
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* Unknown SSL protocol error in connection to github.com:443
* Curl_done
* Closing connection 0
* The cache now contains 0 members
* STATE: WAITPROXYCONNECT => CONNECT handle 0x20081bd0; line 1223 (connection #-5000)
* Couldn't find host github.com in the .netrc file; using defaults
* Added connection 1. The cache now contains 1 members
* Hostname myproxy was found in DNS cache
*   Trying 10.192.45.149...
* STATE: CONNECT => WAITCONNECT handle 0x20081bd0; line 1143 (connection #1)
* Connected to myproxy (10.192.45.149) port 8080 (#1)
* STATE: WAITCONNECT => WAITPROXYCONNECT handle 0x20081bd0; line 1240 (connection #1)
* Establish HTTP proxy tunnel to github.com:443
> CONNECT github.com:443 HTTP/1.1
Host: github.com:443
User-Agent: git/2.5.3
Proxy-Connection: Keep-Alive

* Read response immediately from proxy CONNECT
< HTTP/1.1 407 Proxy Authentication Required
< Proxy-Authenticate: NEGOTIATE
* gss_init_sec_context() failed: : SPNEGO cannot find mechanisms to negotiate
< Proxy-Authenticate: NTLM
< Proxy-Authenticate: BASIC realm="POST_AD"
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Proxy-Connection: close
< Connection: close
< Content-Length: 1025
<
* Received HTTP code 407 from proxy after CONNECT
* Expire cleared
* Curl_done
* Closing connection 1
* The cache now contains 0 members
fatal: unable to access 'https://github.com/gargle/french/': Unknown SSL protocol error in connection to github.com:443

Re: Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

[Johan Laenen]

Enrique Tobis <Enrique.Tobis <at> twosigma.com> writes:

> There is something I don't understand, though. Johan must be configuring
his proxy either a) through git
> config files; or b) through environment variables. Johan says his proxy
uses NTLM authentication. If he
> is doing a), then my change should not have had any impact. We were
already setting CURLOPT_PROXYAUTH to
> CURLAUTH_ANY in that case. If it's b), then his proxy couldn't have been
using NTLM authentication. In the
> old code path, only _BASIC was available as an authentication mechanism.
That default is what prompted me
> to make the change in the first place.

Interesting!

I tried both git versions, the one with the revert of commit 5841520b and
the one without and both gave me the fatal error "Unknown SSL protocol error
in connection to github.com:443" when using the ~/.gitconfig [https] and
[http] proxy settings instead of using the https_proxy environment variable.

Greetings,

Johan

Re: Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

[Junio C Hamano]

[administrivia: please do not cull people out of the Cc: list]

Johan Laenen <johan.laenen+cygwin@gmail.com> writes:

> Enrique Tobis <Enrique.Tobis <at> twosigma.com> writes:
>
>> There is something I don't understand, though. Johan must be
>> configuring his proxy either a) through git config files; or b)
>> through environment variables. Johan says his proxy uses NTLM
>> authentication. If he is doing a), then my change should not have
>> had any impact. We were already setting CURLOPT_PROXYAUTH to
>> CURLAUTH_ANY in that case. If it's b), then his proxy couldn't
>> have been using NTLM authentication. In the old code path, only
>> _BASIC was available as an authentication mechanism.  That
>> default is what prompted me to make the change in the first
>> place.
>
> Interesting!
>
> I tried both git versions, the one with the revert of commit 5841520b and
> the one without and both gave me the fatal error "Unknown SSL protocol error
> in connection to github.com:443" when using the ~/.gitconfig [https] and
> [http] proxy settings instead of using the https_proxy environment variable.

OK, so the conclusion I draw here is that your NTLM setting is not
working at all, you have been using Basic auth happily before that
commit, and you have to either (1) get NTLM auth working, or (2)
find a way to tell Git that your proxy appears to support NTLM
but it is unusable and you need to use Basic.

Even though you may be capable to do (1), other people in the same
situation might not be, in which case we would also need a way to do
(2).

Am I reading the above correctly?

RE: Commit 5841520b makes it impossible to connect to github from behind my company's firewall.

[Enrique Tobis]

From: Junio C Hamano [mailto:jch2355@gmail.com] On Behalf Of Junio C Hamano

[administrivia: please do not cull people out of the Cc: list]

Johan Laenen <johan.laenen+cygwin@gmail.com> writes:

> Enrique Tobis <Enrique.Tobis <at> twosigma.com> writes:
>
>> There is something I don't understand, though. Johan must be 
>> configuring his proxy either a) through git config files; or b) 
>> through environment variables. Johan says his proxy uses NTLM 
>> authentication. If he is doing a), then my change should not have had 
>> any impact. We were already setting CURLOPT_PROXYAUTH to CURLAUTH_ANY 
>> in that case. If it's b), then his proxy couldn't have been using 
>> NTLM authentication. In the old code path, only _BASIC was available 
>> as an authentication mechanism.  That default is what prompted me to 
>> make the change in the first place.
>
> Interesting!
>
> I tried both git versions, the one with the revert of commit 5841520b 
> and the one without and both gave me the fatal error "Unknown SSL 
> protocol error in connection to github.com:443" when using the 
> ~/.gitconfig [https] and [http] proxy settings instead of using the https_proxy environment variable.

> OK, so the conclusion I draw here is that your NTLM setting is not working at all, you have been using Basic auth happily before that commit, and you have to either (1) get NTLM auth working, or (2) find a way to tell Git that your proxy appears to support NTLM but it is unusable and you need to use Basic.

> Even though you may be capable to do (1), other people in the same situation might not be, in which case we would also need a way to do (2).

> Am I reading the above correctly?

I draw almost the same conclusions. I agree that he seems to have been using Basic all along. Based on the verbose output Johan posted, I think libcurl is trying to do NEGOTIATE instead of NTLM, so that's what Johan would have to get working. I also agree that other people may need to do (2).