docker 18.06: proxyconnect tcp: tls: first record does not look like a TLS handshake

[bjonen]

I am using a proxy server to get access to load docker images. The settings have not changed and have worked with all versions before 18.06. Since upgrading I get the following error:

docker pull ubuntu
Using default tag: latest
Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: tls: first record does not look like a TLS handshake

Downgrading as follows resolves the issue:

yum downgrade docker-ce-18.05.0.ce-3.el7.centos

My system:

• Docker version 18.06.0-ce, build 0ffa825
• Linux version 3.10.0-693.17.1.el7.x86_64 (mockbuild@x86-041.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) )

[zenglian]

I downgraded to 17.12.1.ce-1.el7.centos and it works fine now! To find the older versions:

yum list docker-ce --showduplicates | sort -r

[xiaoyulei]

My docker has same problem. Is there new release to solve the problem?

Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:24:51 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:23:15 2018
  OS/Arch:          linux/amd64
  Experimental:     false

[robbmanes]

I had my HTTPS_PROXY value set to https://$PROXY_URL:$PROXY_PORT instead of the correct protocol for my local proxy, which should have been http://$PROXY_URL:$PROXY_PORT. Changing the https to http in my environment solved this problem; obviously mileage may vary depending on your environments.

In a nutshell, I had:

HTTP_PROXY=http://192.168.122.1:3128
HTTPS_PROXY=https://192.168.122.1:3128

When I should have had:

HTTP_PROXY=http://192.168.122.1:3128
HTTPS_PROXY=http://192.168.122.1:3128

Since my proxy didn't support https for the proxy initially:

# openssl s_client -connect 192.168.122.1:3128
CONNECTED(00000003)
140601561139088:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 289 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1546972059
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

I haven't been able to figure out the difference yet, but maybe the HTTPS_PROXY silently fell back to HTTP_PROXY or something like that in earlier versions, and later ones no longer do so.

Hope that helps someone.

[robbmanes]

Looks like this behavior was changed in GoLang:

https://golang.org/doc/go1.10#net/http

So anyone using 'HTTPS_PROXY', I'm assuming the latest Docker was built with Go 1.10, and therefore is affected. Previously, plain HTTP was sent even when using https it appears, and now as per the latest go version it will attempt to honor the https:// with proper TLS. That appears to be here:

golang/go@f5cd386#diff-6951e7593bfb1e773c9121df44df1c36

So anyone hitting this problem, check if your proxy actually supports HTTPS on that port, using openssl s_client -connect or something similar. Otherwise, you should send traffic using plain http to the proxy, and the encapsulation to the registry will be the only SSL/TLS encrypted piece.

[zain-874]

I was using the latest version of docker-ce on kubeadm based cluster. When I downgraded docker-ce to version 17.03.0ce-0ubuntu-xenial, my issue got Resolved.

[prashanthps]

This is happening on docker ver 19.03.5-3 also.

[thaJeztah]

@prashanthps see comment #415 (comment) above

[thaJeztah]

@zain-874 I wouldn't recommend running those old versions; 17.03 reached EOL in june 2017, and has known, critical vulnerabilities

[prashanthps]

Verified proxy supports https on the port. I tried both http and https in the proxy settings. No luck

[anancds]

@robbmanes

I had my HTTPS_PROXY value set to https://$PROXY_URL:$PROXY_PORT instead of the correct protocol for my local proxy, which should have been http://$PROXY_URL:$PROXY_PORT. Changing the https to http in my environment solved this problem; obviously mileage may vary depending on your environments.

In a nutshell, I had:

HTTP_PROXY=http://192.168.122.1:3128
HTTPS_PROXY=https://192.168.122.1:3128

When I should have had:

HTTP_PROXY=http://192.168.122.1:3128
HTTPS_PROXY=http://192.168.122.1:3128

Since my proxy didn't support https for the proxy initially:

# openssl s_client -connect 192.168.122.1:3128
CONNECTED(00000003)
140601561139088:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 289 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1546972059
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

I haven't been able to figure out the difference yet, but maybe the HTTPS_PROXY silently fell back to HTTP_PROXY or something like that in earlier versions, and later ones no longer do so.

Hope that helps someone.

it solved the same problem, thanks