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.

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

Hi,

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

Johan Laenen <johan.laenen+cygwin@gmail.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

-----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:

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

but it does cause libcurl to choose

authentication does your

Hi,

Thanks for looking into this.

I'm behind a NTLM proxy :/

Greetings,

Johan

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

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

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.

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

2015-05-08) where some people had problems with certain cipher the server/client claimed to support when it was in fact broken.

@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.

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

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 :/

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

his proxy either a) through git

uses NTLM authentication. If he

already setting CURLOPT_PROXYAUTH to

using NTLM authentication. In the

That default is what prompted me

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

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

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

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?

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:

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).