Unknown SSL protocol error with HTTPS proxy decryption #373

galehar · 2015-09-10T10:01:46Z

Since my company implemented HTTPS proxy decryption through bluecoat SSLVA, git 2.5.1 is unable to connect to the repository with https. I always get the error :

Unknown SSL protocol error in connection to ...

I did install the CA certificate from the company and I set http.sslCAInfo to point to it. The certificate is properly set, but I still get the Unkown SSL protocol error.

successfully set certificate verify locations:
CAfile: C:\Program Files\Git\mingw64/ssl/CompanyCA.pem

Setting http.sslVerify to false doesn't fix the problem, still the same issue.

I tried with curl to diagnose, and setting the CA certificate with the cacert option allows me to connect successfully, and so does using the insecure option.

I also tried with an old git version 1.9.4.msysgit.2, and with it, I've also been able to successfully connect by setting sslCAInfo properly or disabling sslVerify.

git 2.5.1 on the other hand doesn't work at all. I tried both 32 and 64 bit versions. This is on Windows 7 SP1 64 bits.

shiftkey · 2015-09-10T12:09:17Z

@galehar could you try cloning with all the diagnostics enabled? My psychic debugger thinks something network-related is involved:

GIT_TRACE=1; GIT_CURL_VERBOSE=1; git ...

Feel free to strip out sensitive stuff, but there should be some extra info in here to help us troubleshoot further.

galehar · 2015-09-10T12:22:53Z

Here is a trace of the connection with the sensitive stuff replaced.

git pull
14:17:18.090286 git.c:558 trace: exec: 'git-pull'
14:17:18.091287 run-command.c:347 trace: run_command: 'git-pull'
14:17:18.312309 git.c:348 trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--'
14:17:18.421320 git.c:348 trace: built-in: git 'rev-parse' '--git-dir'
14:17:18.493327 git.c:348 trace: built-in: git 'rev-parse' '--git-path' 'objects'
14:17:18.573335 git.c:348 trace: built-in: git 'rev-parse' '--is-bare-repository'
14:17:18.619339 git.c:348 trace: built-in: git 'rev-parse' '--show-toplevel'
14:17:18.668344 git.c:348 trace: built-in: git 'ls-files' '-u'
14:17:18.715349 git.c:348 trace: built-in: git 'symbolic-ref' '-q' 'HEAD'
14:17:18.869364 git.c:348 trace: built-in: git 'config' 'pull.ff'
14:17:18.914369 git.c:348 trace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD'
14:17:18.956373 git.c:348 trace: built-in: git 'rev-parse' '--verify' 'HEAD'
14:17:18.999377 git.c:348 trace: built-in: git 'update-index' '-q' '--ignore-submodules' '--refresh'
14:17:19.076385 git.c:348 trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules'
14:17:19.151393 git.c:348 trace: built-in: git 'diff-index' '--cached' '--quiet' '--ignore-submodules' 'HEAD' '--'
14:17:19.248402 git.c:348 trace: built-in: git 'rev-parse' '-q' '--git-dir'
14:17:19.575435 git.c:348 trace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD'
14:17:19.616439 git.c:348 trace: built-in: git 'fetch' '--update-head-ok'
14:17:19.619439 run-command.c:347 trace: run_command: 'git-remote-https' 'origin' 'https://mygitserver.company.com/git/repository-name'

Couldn't find host www.hostname.com in the _netrc file; using defaults
timeout on name lookup is not supported
Trying ip_of_proxy...
Connected to autoconf (ip_of_proxy) port 3128 (#0)
Establish HTTP proxy tunnel to mygitserver.company.com:443

CONNECT mygitserver.company.com:443 HTTP/1.1
Host: mygitserver.company.com:443
User-Agent: git/2.5.1.windows.1
Proxy-Connection: Keep-Alive

< HTTP/1.1 407 Proxy Authentication Required
< Proxy-Authenticate: NTLM
< Proxy-Authenticate: BASIC realm="Company_NTLM"
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Proxy-Connection: close
< Set-Cookie: BCSI-CS-05ae2b15ff1376d7=2; Path=/
< Connection: close
< Content-Length: 1672
<

Ignore 1672 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: C:\Program Files\Git\mingw64/ssl/CompanyCA.pem
CApath: none
Unknown SSL protocol error in connection to mygitserver.company.com:443
Closing connection 0
Couldn't find host mygitserver.company.com in the _netrc file; using defaults
timeout on name lookup is not supported
Hostname autoconf was found in DNS cache
Trying ip_of_proxy...
Connected to autoconf (ip_of_proxy) port 3128 (Fixes for the new SDK #1)
Establish HTTP proxy tunnel to mygitserver.company.com:443
Proxy auth using NTLM with user 'ProxyUserName'

CONNECT mygitserver.company.com:443 HTTP/1.1
Host: mygitserver.company.com:443
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==
User-Agent: git/2.5.1.windows.1
Proxy-Connection: Keep-Alive

dscho · 2015-09-17T21:39:58Z

Since 1.9.5 works, you could compare the verbose output of both...

galehar · 2015-09-18T09:47:28Z

Well, I did compare the verbose output, but I didn't learn anything from it. With git 1.9.4, I get "SSL connection using DHE-RSA-AES256-SHA" and with git 2.5.1: "Unknown SSL protocol error in connection to mygitserver.company.com:443". Besides, the problem is not related to https decryption. It has been disabled today, and I can connect with git 1.9.4 without having to mess with sslCAInfo or sslVerify. Still same error with git 2.5.1.
Also, I tried git 1.9.5, and I get the same error as with 2.5.1. Only git 1.9.4 works.

Here is the full log of the successful connection with git 1.9.4:

$ git fetch
trace: built-in: git 'fetch'
trace: run_command: 'git-remote-https' 'origin' 'https://mygitserver.company.com/git/repository-name'

Couldn't find host mygitserver.company.com in the _netrc file; using defaults
Adding handle: conn: 0x1e81a48
Adding handle: send: 0
Adding handle: recv: 0
Curl_addHandleToPipeline: length: 1
- Conn 0 (0x1e81a48) send_pipe: 1, recv_pipe: 0
About to connect() to proxy autoconf port 3128 (#0)
Trying ip_of_proxy...
Connected to autoconf (ip_of_proxy) port 3128 (#0)
Establish HTTP proxy tunnel to mygitserver.company.com:443

CONNECT mygitserver.company.com:443 HTTP/1.1
Host: mygitserver.company.com:443
User-Agent: git/1.9.4.msysgit.2
Proxy-Connection: Keep-Alive
Pragma: no-cache

< HTTP/1.1 407 Proxy Authentication Required
< Proxy-Authenticate: NTLM
< Proxy-Authenticate: BASIC realm="Airbus_NTLM"
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Proxy-Connection: close
< Set-Cookie: BCSI-CS-eef0d1994df46519=2; Path=/
< Connection: close
< Content-Length: 1672
<

Ignore 1672 bytes of response-body
Received HTTP code 407 from proxy after CONNECT
Couldn't find host mygitserver.company.com in the _netrc file; using defaults
Found bundle for host mygitserver.company.com: 0x1e64508
About to connect() to proxy autoconf port 3128 (Fixes for the new SDK #1)
Trying ip_of_proxy...
Adding handle: conn: 0x1e93898
Adding handle: send: 0
Adding handle: recv: 0
Curl_addHandleToPipeline: length: 1
- Conn 0 (0x1e81a48) send_pipe: 1, recv_pipe: 0
- Conn 1 (0x1e93898) send_pipe: 1, recv_pipe: 0
Connected to autoconf (ip_of_proxy) port 3128 (Fixes for the new SDK #1)
Establish HTTP proxy tunnel to mygitserver.company.com:443
Proxy auth using NTLM with user 'ProxyUserName'

CONNECT mygitserver.company.com:443 HTTP/1.1
Host: mygitserver.company.com:443
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAt4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw
==
User-Agent: git/1.9.4.msysgit.2
Proxy-Connection: Keep-Alive
Pragma: no-cache

< HTTP/1.1 407 Proxy Authentication Required
< Proxy-Authenticate: NTLM TlRMTVNTUAACAAAABAAEADgAAAA1goniglnfoWEAazAAAAAAAAAAA
JwAnAA8AAAABQLODgAAAA9FAFUAAgAEAEUAVQABABgARgBSADAALQBIAEkAUABFAC0AUAAwADIABAAcA
GUAdQAuAGEAaQByAGIAdQBzAC4AYwBvAHIAcAADADYAZgByADAALQBoAGkAcABlAC0AcAAwADIALgBlA
HUALgBhAGkAcgBiAHUAcwAuAGMAbwByAHAABQAWAGEAaQByAGIAdQBzAC4AYwBvAHIAcAAAAAAA
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Proxy-Connection: Keep-Alive
< Set-Cookie: BCSI-CS-eef0d1994df46519=2; Path=/
< Connection: Keep-Alive
< Content-Length: 1723
<

Ignore 1723 bytes of response-body
TUNNEL_STATE switched to: 0
Establish HTTP proxy tunnel to mygitserver.company.com:443
Proxy auth using NTLM with user 'ProxyUserName'

CONNECT mygitserver.company.com:443 HTTP/1.1
Host: mygitserver.company.com:443
Proxy-Authorization: NTLM TlRMTVNTUAADAAAAGAAYAIAAAAAYARgBmAAAAAAAAABYAAAADgAOAF
gAAAAaABoAZgAAABAAEACwAQAANYKI4gYBsR0AAAAPMlKWX0k8kdZcXg8bfalwTW4AZwAxADIANgBjAD
gAVABPAEwAWAAzADAAMAAwADgANgAzADcANgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADF6Ngb5akgVV
EgQHSr5iu6AQEAAAAAAABYbl608/HQAbgPzHO2QWF6AAAAAAIABABFAFUAAQAYAEYAUgAwAC0ASABJAF
AARQAtAFAAMAAyAAQAHABlAHUALgBhAGkAcgBiAHUAcwAuAGMAbwByAHAAAwA2AGYAcgAwAC0AaABpAH
AAZQAtAHAAMAAyAC4AZQB1AC4AYQBpAHIAYgB1AHMALgBjAG8AcgBwAAUAFgBhAGkAcgBiAHUAcwAuAG
MAbwByAHAACAAwADAAAAAAAAAAAQAAAAAgAACEt1DOFPJM4ledS5wPhxxN9Owm2QS6fh+YVRXucngZBQ
oAEAAAAAAAAAAAAAAAAAAAAAAACQAAAAAAAAAAAAAAr9QCeUrjDrzmdBsMLt3l+Q==
User-Agent: git/1.9.4.msysgit.2
Proxy-Connection: Keep-Alive
Pragma: no-cache

< HTTP/1.1 200 Connection established
<

Proxy replied OK to CONNECT request
successfully set certificate verify locations:
CAfile: C:\Users\ProxyUserName\Documents\GitPortable\App\Git/bin/curl-ca-bundle.crt
CApath: none
SSL connection using DHE-RSA-AES256-SHA
Server certificate:
```
   subject: stripped certificate info
```
```
   start date: 2014-10-15 00:00:00 GMT
```

   expire date: 2015-10-15 23:59:59 GMT

   subjectAltName: mygitserver.company.com matched

   issuer: stripped issuer certificate info

```
   SSL certificate verify ok.
```
GET /git/repository-name/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.9.4.msysgit.2
Host: mygitserver.company.com
Accept: /
Accept-Encoding: gzip
Pragma: no-cache

< HTTP/1.1 401 Authorization Required

Server nginx is not blacklisted
< Server: nginx
< Date: Fri, 18 Sep 2015 09:23:40 GMT
< Content-Type: text/html; charset=iso-8859-1
< Content-Length: 495
< Connection: keep-alive
< WWW-Authenticate: Basic realm="Git Authentication"
<
Connection Fixes for the new SDK #1 to host autoconf left intact
trace: run_command: 'git credential-wincred get'
trace: exec: 'git-credential-wincred' 'get'
trace: run_command: 'git-credential-wincred' 'get'
Couldn't find host mygitserver.company.com in the _netrc file; using defaults
Found bundle for host mygitserver.company.com: 0x1e64508
Re-using existing connection! (Fixes for the new SDK #1) with host autoconf
Connected to autoconf (ip_of_proxy) port 3128 (Fixes for the new SDK #1)
Adding handle: conn: 0x1e93898
Adding handle: send: 0
Adding handle: recv: 0
Curl_addHandleToPipeline: length: 1
- Conn 0 (0x1e81a48) send_pipe: 1, recv_pipe: 0
- Conn 1 (0x1e93898) send_pipe: 1, recv_pipe: 0

GET /git/repository-name/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.9.4.msysgit.2
Host: mygitserver.company.com
Accept: /
Accept-Encoding: gzip
Pragma: no-cache

< HTTP/1.1 401 Authorization Required

Server nginx is not blacklisted
< Server: nginx
< Date: Fri, 18 Sep 2015 09:23:40 GMT
< Content-Type: text/html; charset=iso-8859-1
< Content-Length: 495
< Connection: keep-alive
< WWW-Authenticate: Basic realm="Git Authentication"
<
Ignoring the response-body
Connection Fixes for the new SDK #1 to host autoconf left intact
Issue another request to this URL: 'https://mygitserver.company.com/git/repository-name/info/refs?service=git-upload-pack'
Couldn't find host mygitserver.company.com in the _netrc file; using defaults
Found bundle for host mygitserver.company.com: 0x1e64508
Re-using existing connection! (Fixes for the new SDK #1) with host autoconf
Connected to autoconf (ip_of_proxy) port 3128 (Fixes for the new SDK #1)
Adding handle: conn: 0x1e93898
Adding handle: send: 0
Adding handle: recv: 0
Curl_addHandleToPipeline: length: 1
- Conn 0 (0x1e81a48) send_pipe: 1, recv_pipe: 0
- Conn 1 (0x1e93898) send_pipe: 1, recv_pipe: 0
Server auth using Basic with user 'rlangella'

GET /git/repository-name/info/refs?service=git-upload-pack HTTP/1.1
Authorization: Basic cmxhbmdlbGxhOnJsYW5nZWxsYQ==
User-Agent: git/1.9.4.msysgit.2
Host: mygitserver.company.com
Accept: /
Accept-Encoding: gzip
Pragma: no-cache

< HTTP/1.1 200 OK

Server nginx is not blacklisted
< Server: nginx
< Date: Fri, 18 Sep 2015 09:23:41 GMT
< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Connection: keep-alive
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< X-Frame-Options: ALLOW
< Front-End-Https: on
< Strict-Transport-Security: max-age=15768000
< X-Frame-Options: SAMEORIGIN
< X-UA-Compatible: IE=EmulateIE8
<
Connection Fixes for the new SDK #1 to host autoconf left intact
trace: run_command: 'git credential-wincred store'
trace: exec: 'git-credential-wincred' 'store'
trace: run_command: 'git-credential-wincred' 'store'
trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all'
trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all'
trace: run_command: 'gc' '--auto'
trace: built-in: git 'gc' '--auto'

dscho · 2015-09-18T10:19:41Z

Unknown SSL protocol error in connection to mygitserver.company.com:443

Without SSL, you certainly do not get this error with 1.9.5 and 2.5.1. What do you get instead?

galehar · 2015-09-18T11:50:36Z

What do you mean without SSL? I can't disable SSL, I can only connect to the repository via https. The https decryption module for the proxy has been disabled, so it's not messing with certificates anymore. I can set sslVerify to false to disable certificate verification, but I still have to use SSL.

dscho · 2015-09-18T12:53:56Z

What do you mean without SSL?

Well, I took the meaning of

Besides, the problem is not related to https decryption. It has been disabled today

too literal, I guess.

dscho · 2015-09-18T14:17:03Z

The best strategy from here would be to reduce the problem. If you can test with a host that does not need to go through the proxy, you could find out whether it is actually the proxy that does bad things. Try to think of ways to take out as much as possible, until you hit a spot where taking away one block "fixes" things. That way, you could identify the real culprits better and we have a chance of finding a solution for you.

dscho · 2015-09-22T09:04:07Z

@galehar any luck yet with the investigation?

galehar · 2015-09-22T09:17:34Z

Well, I tested from another network with a different proxy, and it worked fine. It was a different computer, but with the same OS and same git version.
I also tested another repository on github, and I could clone it without any problem.
So, in the end, it seems that the problem arises from a combination of factors from the proxy and the git repository (or maybe the reverse proxy in front of it?).
Unfortunately, I don't have access to neither, some I'm not sure how to procede from there. Maybe I could ask for repository or reverse proxy log. I might be able to try a network trace, but I'm not sure I'll be able to interpret the result.

dscho · 2015-09-22T15:56:05Z

You could test with curl on the machine that has the problem. And then you could also set up your own server and force the proxy to connect to it and see whether the problem still occurs.

It is possible that the proxy gets confused with WebDAV commands...

soltmar · 2015-09-28T11:23:08Z

Hi,

This is related to my original post here:

msysgit/msysgit#23 (comment)

I have exactly same issue.

Everything is working correctly in 1.9.0 and 1.9.5 git versions but not with latest one ( 2.5.3 )

I've got exactly the same CURL Verbose output as @galehar

Resulting in "Unknown SSL protocol error in connection to bitbucket:443" (Original output in the link
above)
I wasn't able to resolve that in any way.

Connection to my proxy is going through http (we don't have https proxy set).

I've got Env Vars set in this way:

HTTP_PROXY = http://user:pass@proxy.com:8080
HTTPS_PROXY = http://user:pass@proxy.com:8080

Please note http in HTTPS_PROXY.

This configuration works perfectly for 1.9 and 1.9.5 as mentioned on the beginning.

Any ideas ?

dscho · 2015-09-28T11:43:36Z

I tried with curl to diagnose, and setting the CA certificate with the cacert option allows me to connect successfully

Could you compare the verbose output of curl.exe with the verbose output of the git fetch call?

galehar · 2015-09-28T12:05:01Z

Here is the curl output. I used -x option and didn't bother to authenticate on the repo. I can try to change that if you want. By the way, I have been able to replicate the issue with another repository. I really think the problem is caused by the proxy.

$ curl -v -k https://mygitserver.company.com/git/repository-name -x autoconf:3128 -U ProxyUserName:ProxyPassword
* timeout on name lookup is not supported
*   Trying 44.62.3.95...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to autoconf (44.62.3.95) port 3128 (#0)
* Establish HTTP proxy tunnel to mygitserver.company.com:443
* Proxy auth using Basic with user 'ProxyUserName'
> CONNECT mygitserver.company.com:443 HTTP/1.1
> Host: mygitserver.company.com:443
> Proxy-Authorization: Basic bmcxMjZjODoxYWFzc0dvdzUwOQ==
> User-Agent: curl/7.44.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied OK to CONNECT request
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [111 bytes data]
* NPN, negotiated HTTP1.1
{ [5 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3321 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [365 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [102 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Unknown (67):
} [36 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*        stripped out certificate info
*        SSL certificate verify ok.
} [5 bytes data]
> GET /git/repository-name HTTP/1.1
> Host: mygitserver.company.com
> User-Agent: curl/7.44.0
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 401 Authorization Required
< Server: nginx
< Date: Mon, 28 Sep 2015 11:58:52 GMT
< Content-Type: text/html; charset=iso-8859-1
< Content-Length: 495
< Connection: keep-alive
* Authentication problem. Ignoring this.
< WWW-Authenticate: Basic realm="Git Authentication"
<
{ [495 bytes data]
100   495  100   495    0     0   1320      0 --:--:-- --:--:-- --:--:--  1443<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Authorization Required</title>
</head><body>
<h1>Authorization Required</h1>
<p>This server could not verify that you
are authorized to access the document
requested.  Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
<hr>
<address>Apache/2.2.15 (CentOS) Server at mygitserver.company.com Port 80</address>
</body></html>

* Connection #0 to host autoconf left intact

dscho · 2015-09-28T12:54:59Z

@galehar I actually really was asking to compare the output, not to make me compare the output... ;-)

BTW I surrounded your pasted log with proper Markdown so that I do not get eye cancer.

dscho · 2015-09-28T12:59:35Z

@marsoltys maybe you can perform the analysis? My idea was to compare how git fetch negotiates with the proxy/server combo vs Git for Windows' curl.exe.

soltmar · 2015-09-28T13:21:28Z

I'm not sure how to pass password for repository as I'm already using -U for proxy details

$ curl --verbose https://username@bitbucket.org/reponame/devt ools.git -U proxyuser:proxypass

dscho · 2015-09-28T13:26:00Z

You can configure proxies via the http_proxy and https_proxy environment variables. When you do that, you can pass the user name and password directly in those variables.

galehar · 2015-09-28T14:24:25Z

@dscho ok, here is what I've got with the curl / git comparison:
Between Establish HTTP proxy tunnel and CONNECT lines, curl has an additional line:

Proxy auth using Basic with user 'ProxyUserName'

Then, between Host and User-Agent lines, it has an additionnal Proxy-Authorization line.
After that, curl receives an HTTP 200 whereas git receives an HTTP 407. So, it seems to me that proxy authentication is not working properly in this case.

soltmar · 2015-09-28T15:03:35Z

I'm providing diff file with output from Git 1.9.5 and 2.5.3

https://www.dropbox.com/s/dyef5hby6mcvdxp/9EeIzRPQ.diff?dl=0
(I was unable to attach file here - even txt)

In my case first request / connection under 2.5.3 is failed "Unknown SSL..." - this is proxy request
Then there is again successful connection to proxy and request to bitbucket.
It looks like at some point proxy connection is lost and then after providing password to Bitbucket Proxy is asking for authentication but it looks like it fails

< HTTP/1.1 407 Proxy Authentication Required
< Proxy-Authenticate: NTLM
< Proxy-Authenticate: BASIC realm="xxxx



"
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Proxy-Connection: close


< Connection: close
< Content-Length: 849
<
* Ignore 849 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: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
  CApath: none
* SSL re-using session ID
* Unknown SSL protocol error in connection to bitbucket.org:443
* Closing connection 2

One line is interesting (don't know if this mean something):
SSL re-using session ID

So if actual Proxy connection has been lost curl is not able to re-use session ID ?

dscho · 2015-09-28T16:42:12Z

I have a hunch that curl/curl@f65e07c might fix this.

galehar · 2015-09-29T09:25:14Z

I confirm the fix! I cloned the curl repo, compiled it, and replaced "C:\Program Files\Git\mingw64\libexec\git-core\libcurl-4.dll" with it. And it works!
Thanks.

dscho · 2015-09-29T09:25:27Z

Awesome! Thanks!

dscho · 2015-09-29T09:30:44Z

The proper course of action now is to determine how to fix this in Git for Windows. I see two options:

cherry-pick the patch and apply it as part of https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-curl/PKGBUILD
switch https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-curl/PKGBUILD to use cURL's current master (i.e. not an officially released version)

My preference would be 1.

@galehar would you have time to help me do that?

dscho · 2015-09-29T09:37:23Z

Okay, I'll start working on it.

galehar · 2015-09-29T09:40:04Z

Sure I can help, although I'm not sure how. Do you need me to test something?

dscho · 2015-09-29T09:40:57Z

I'll work on that PKGBUILD file, as I indicated. I will probably soon have a Pacman package to test. Did you install the Git for Windows SDK already?

dscho · 2015-09-29T10:23:24Z

@galehar assuming that you have an SDK, could you please download the package for your architecture from https://github.com/dscho/MINGW-packages/releases/tag/tmp-curl-ntlm-fix and install it with pacman -U, then verify that it indeed fixes things?

Under certain circumstances, an NTLM proxy connection will be reused. If that is the case, the state of the authentication needs to be handled properly. There is a bug in cURL 7.44.0 that has been fixed in cURL's `master` already (curl/curl@f65e07ca5) and this patch backports it. This fixes git-for-windows/git#373 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

soltmar · 2015-09-29T13:30:42Z

When this will be available in release ?

dscho · 2015-09-29T13:31:14Z

@marsoltys you'll have to wait and see.

soltmar · 2015-09-29T13:32:04Z

Ok.

Thanks anyway for sorting this out!

dscho · 2015-09-29T13:34:40Z

@marsoltys well, you could thank me by trying it out.

galehar · 2015-09-29T13:41:53Z

Alright, I have installed the SDK and tested mingw-w64-x86_64-curl-7.44.0-3-any.pkg.tar.xz. It works.

dscho · 2015-09-29T13:54:31Z

@galehar perfect, thanks!

soltmar · 2015-09-29T15:00:26Z

@dscho I'm not able to install SDK

When installer asks me for proxy I'm giving it in format

http://user:pass@proxy.example.com:8080

after that it hangs...

galehar · 2015-09-29T15:05:42Z

Maybe it's not really hanged, it spends a lot of time downloading packages. The first time, I thought it hanged. I killed it, deleted the lock filed and restarted the installer. It worked the second time for me.

dscho · 2015-09-29T15:22:33Z

@marsoltys please do not high-jack this ticket. Open a new one, and give a verbose description and be liberal with pasting output verbatim.

dscho · 2015-09-29T21:09:47Z

Git for Windows 2.6.0 comes with a fixed cURL. Let's hope that MSys2 picks up my Pull Request soon, then I can close this ticket.

dscho · 2015-10-01T13:30:48Z

I'm not able to install SDK

When installer asks me for proxy I'm giving it in format

http://user:pass@proxy.example.com:8080

after that it hangs...

@marsoltys is it really too much to ask for a new ticket? In any case, I believe that I addressed this (it is most likely not hanging, just like @galehar suggested, but we won't know until you grace us with an answer to his question).

soltmar · 2015-10-01T15:17:35Z

I'm working in corporate environment and not always have time to answer / log a new ticket ...

At home I do not have the same proxy so won't be able to investigate / reproduce steps made at work :)

soltmar · 2015-10-05T12:42:43Z

Package https://github.com/dscho/MINGW-packages/releases/tag/tmp-curl-ntlm-fix tested with SDK and I can confirm that it works.

dscho · 2015-10-05T12:54:41Z

@marsoltys thank you very much! It would appear that the new package was uploaded today. So I will close this ticket.

…alized-vars Avoid using uninitialized variables in `format_tracking_info()`

dscho added unclear pending-answer labels Sep 18, 2015

dscho mentioned this issue Sep 29, 2015

curl: fix NTLM proxy when reusing connection msys2/MINGW-packages#806

Merged

soltmar mentioned this issue Oct 1, 2015

Git for Windows SDK 1.0.1 - error: failed to update mingw32 (error invoking external downloader) #458

Closed

dscho closed this as completed Oct 5, 2015

ciis0 mentioned this issue Oct 10, 2016

Plain HTTP Auth Proxy & "Unknown SSL protocol error in connection to ..." #913

Closed

1 task

jeffhostetler pushed a commit to jeffhostetler/git that referenced this issue Jun 21, 2021

Merge pull request git-for-windows#373 from dscho/avoid-using-uniniti…

2f9b245

…alized-vars Avoid using uninitialized variables in `format_tracking_info()`

Unknown SSL protocol error with HTTPS proxy decryption #373

Unknown SSL protocol error with HTTPS proxy decryption #373

Comments

galehar commented Sep 10, 2015

shiftkey commented Sep 10, 2015

galehar commented Sep 10, 2015

dscho commented Sep 17, 2015

galehar commented Sep 18, 2015

dscho commented Sep 18, 2015

galehar commented Sep 18, 2015

dscho commented Sep 18, 2015

dscho commented Sep 18, 2015

dscho commented Sep 22, 2015

galehar commented Sep 22, 2015

dscho commented Sep 22, 2015

soltmar commented Sep 28, 2015

dscho commented Sep 28, 2015

galehar commented Sep 28, 2015

dscho commented Sep 28, 2015

dscho commented Sep 28, 2015

soltmar commented Sep 28, 2015

dscho commented Sep 28, 2015

galehar commented Sep 28, 2015

soltmar commented Sep 28, 2015

dscho commented Sep 28, 2015

galehar commented Sep 29, 2015

dscho commented Sep 29, 2015

dscho commented Sep 29, 2015

dscho commented Sep 29, 2015

galehar commented Sep 29, 2015

dscho commented Sep 29, 2015

dscho commented Sep 29, 2015

soltmar commented Sep 29, 2015

dscho commented Sep 29, 2015

soltmar commented Sep 29, 2015

dscho commented Sep 29, 2015

galehar commented Sep 29, 2015

dscho commented Sep 29, 2015

soltmar commented Sep 29, 2015

galehar commented Sep 29, 2015

dscho commented Sep 29, 2015

dscho commented Sep 29, 2015

dscho commented Oct 1, 2015

soltmar commented Oct 1, 2015

soltmar commented Oct 5, 2015

dscho commented Oct 5, 2015