Unable to connect with TLS

[md5]

I attempted to use the HTTPClient field to configure TLS support, but was unsuccessful. I get the following error:

Get http://192.168.59.103:2376/containers/json: malformed HTTP response "\x15\x03\x01\x00\x02\x02"

I believe the problem is here: https://github.com/fsouza/go-dockerclient/blob/master/client.go#L521-L523

Even though I'm setting a Transport on my HTTPClient, it's still trying to use HTTP instead of HTTPS because it doesn't know in those lines that my "tcp" connection actually needs to be HTTPS.

My code is here: https://github.com/md5/docker-gen/compare/tls-support

[md5]

My DOCKER_HOST/endpoint value is tcp://192.168.59.103:2376, since I'm using boot2docker. I tried changing it to https://192.168.59.103:2376, but then I got this error, both from go-dockerclient and from docker itself: Invalid bind address protocol: https://192.168.59.103:2376

[didip]

I got further along and hit a different problem.

I changed my docker host endpoint to https://192.168.59.103:2376 and now I got this error:
x509: certificate signed by unknown authority.

It looks like the HTTP client is not finding .boot2docker/certs/boot2docker-vm/cert.pem

[fsouza]

Hi @md5 @didip, there's a pull request (#169) adding TLS supports, but it doesn't handle the tcp:// yet.

One way we could approach this is using https when the port is 2376 and http when it is 2375. What do you think?

[md5]

Checking the port number feels like a hack. Looking at how docker/docker is doing it, perhaps a good approach would be to check if c.HTTPClient.Transport.TLSConfig != nil right here and change the scheme on req to HTTPS. That also feels like a hack, but at least it's the same hack the standard docker client is making :)

[md5]

Still, the port number thing should be pretty safe.

[md5]

Now that I've had a closer look at #169, I think that having separate methods is the right approach. However, I think it might be good for parseEndpoint to simply return the "tcp:" prefix and have the calls to it in NewVersionedClient and NewVersionedTLSClient set the scheme appropriately. I'll make a comment on that PR since I also have a suggestion about the CA cert issue.

[rafecolton]

Agreed that guessing based on port seems like a hack. What if boot2docker decides to change the ports? Or what if somebody is already using 2375 on their host machine and they have it mapped to something else? etc.

I'm inclined to agree that different methods is the best way to handle things - will maintain backwards compatibility / avoid unexpected behavior

[fsouza]

No, it's not a hack. 2375 is the port reserved for non-secure traffic on Docker (docker), and 2376 is for TLS-based traffic (docker-s). It is as safe as assuming that 80 is HTTP and 443 is HTTPS.

It is not a boot2docker thing, these ports are registered in the IANA registry,

[md5]

Understood. Sorry if I've offended you by calling your proposal a hack.

[md5]

I'm going to close this since #169 is tracking the fix.

[fsouza]

No problem at all, you haven't offended me! :) Thanks for contributing to the discussion and the project!

[md5]

Cool. Perhaps the next thing to get merged will be this NewClientFromEnv code I worked on last night: https://github.com/md5/go-dockerclient/commit/4a6086a116c0fd940945272952a9af43028a3f3e

[md5]

Seeing that you just merged the TLS changes, I rebased this: https://github.com/md5/go-dockerclient/compare/new-client-from-env

[md5]

I can add docs and tests if you're interested in a PR.

[fsouza]

Hi @md5, are these environment variables used elsewhere? Do they come from boot2docker? At first, I dislike the idea of handling environment variables, but I'd like to make sure I fully understand the use case.

Thank you again!

[md5]

They're the same ones used by docker itself. Boot2docker doesn't have a separate Docker client; it relies on support in the stock client.

[progrium]

+1 ... @md5's new-client-from-env needs to get in

[gerred]

👍