How to disable TLS?

[linux-china]

I have developed some tools with 2375 port, and how to start boot2docker without tls support?

[SvenDowideit]

Heya @linux-china sorry, it looks like we all overlooked this - I've made a PR that will resolve it - if you need something now, you can grab the code and build your own iso (see https://github.com/boot2docker/boot2docker/blob/master/doc/BUILD.md for how)

[softprops]

I ran into this problem as well. Was there a reason this was a default? It's probably going to break a lot of tools.

[ewindisch]

TLS authentication is now required in boot2docker 1.3. We believe that boot2docker is principally used on desktop systems where users also tend to use web browsers. It was determined that without authentication to the Docker socket, browsers could access and control Docker and, subsequently, perform management on Docker containers. The Docker API is equivalent to root access on the system and unauthenticated access to this API is ill-advised. For that reason, we have made authentication a default requirement. We issued two CVEs related to this change (CVE-2014-5280 and CVE-2014-5279).

You may find the CVEs here: https://groups.google.com/forum/#!topic/docker-announce/aQoVmQlcE0A

[lalyos]

I have a workaround: I keep the daemon using TLS and running on 2376, but start a proxy container:

$(docker run sequenceiq/socat)

It starts a container with socat proxying the /var/run/docker.sock on port 2375. So you can reach Docker the old way, like: curl http://192.168.59.103:2375/_ping

[dweinstein]

@lalyos nice workaround. I think it's great that docker is moving to being more secure by default, but there are some legacy (mostly for testing) docker environments that benefit from this type of workaround.

[sfitts]

@ewindisch that's great -- unfortunately it breaks all of the current maven/gradle build plug-ins. So having the option to turn it off seems like a reasonable compromise. Docker is becoming increasingly important core infrastructure (for us at least), so I'm hoping there will be more focus on maintaining compatibility (of the entire environment) across releases.

@SvenDowideit -- thanks -- any idea when this will make it into a patch?

[detro]

In addition from this change being forceful (and inconsiderate), I have had another issue: boot2docker always downloads the latest image. So even if I downgrate to 1.1.2, still it's going to fetch 1.3.0. Causing total breakage of my dev environment.

Version 1.1.2 should dowload version 1.1.2.
I had to manually put the 1.1.2 .iso into my .boot2docker directory to resume work.

It's ridiculous how many times Docker has caused API incompatibility from one version to another.

And, if you look to the Release Notes, very little is said about those choices.

I TOTALLY see the need for TLS in production, and offering it even as part of boot2docker makes sense. But you guys have reached enough ciritical mass now: you need to make changes slowly. Particularly if we are not talking about MAJOR changes!

I'm still using 1.1.2! 1.2.0 port mapping for http is gone and creates all sort of issues for us while developing on Mac. Think about it...

[SvenDowideit]

@detro what do you mean port mapping is gone ? (do you mean the boot2docker port forwarding on localhost?)

[detro]

Yep
On 20 Oct 2014 18:33, "Sven Dowideit" notifications@github.com wrote:

@detro https://github.com/detro what do you mean port mapping is gone ?
(do you mean the boot2docker port forwarding on localhost?)

—
Reply to this email directly or view it on GitHub
#571 (comment)
.

[SvenDowideit]

@detro we replaces that with the host only network - because the NAT port forwarding was unreliable.

if you need to expose your containers to other users on your LAN, then you can follow the directions in the documentation to do that - or if you have a little time - there was a proposal to add some code to boot2docker to make that simpler.

if you're doing local testing - point your browser at http://192.168.59.103 :)

[detro]

@SvenDowideit I finally can take a sit and be a bit more "verbose".
I appreciate the quality of the changes. And the need.

What I'm complaining about (and I think I'm not alone here) is the procedure with which changes seems to be done in this project and even the Docker project.

Assuming that all the ppl that are adopting it are constantly up to date with the "community-to-dev-to-community" comms is wrong: Docker has quickly (maybe too quickly) grown into a commonly known, production tool.
Unless you (a generic "you") are in the business of Container technologies, your interest isn't following Docker latest/greatest news - it's about using Docker to deploy your stuff on it.
When a new version is released, and the version is a 1.x.y, you assume a few things (common in other project) 1) if I switch to it, it's not going to break my code as it should not have API or behavioural changes 2) I'll look at the Changelog just so I'm sure I can switch safely.

Instead, in 1.2.0, all of a sudden, this port mapping changed for boot2docker: that immediately rendered all our HTTP-based Docker client (that bound to localhost:2375) dead in the water. We pocked things around, and figured what happened. A good half day of work was gone just because this little change was made "default behaviour".
Bear in mind, all the production servers were fine: was the devs that were affected.

Not 1.3.0 makes the use of certificates mandatory. The http-based client is dead in the water again, this time requiring code changes so that we probably can't quickly patch and keep going.

In production, it's definitely something we want to spend time and setup, but it's now going to be put on hold until "we have time". The fact that to use 1.3.0 on my dev box I got to spend time reworking our client it's just a no brainer for "I can't do this right now - too many other things to do".

Feel free to add new features. Fix bugs. Improve security.
But you should make an effort at 1) maintaining compatibility with what's running (unless you are releasing a 2.x) and 2) boot2docker is a development tool - I don't need to setup certificates to communicated with a docker host that is running in my VirtualBox.

In short, you are being your own enemy. How long before someone else decides to make their own LXC technology, building upon all the lessons you guys have learned in the meantime?

Docker is a tool used by devs and DevOps: you need to pass on the "feeling" that is a reliable and solid technology. Not the feeling that every release is a roller-coaster. It really works against your amazing effort.

All that said, keep making awesome. Maybe a little slower if you can :)

[SvenDowideit]

yeah - the breaking changes are painful, sorry :/

the localhost mapping was changed before the 1.0 release - and we'd kept the NAT mapping for about 3 months before turning it off - I guess we need to work out a way to get the info out to more people.

the TLS compulsory for all b2d is sadly, extremely important for dev as well as everyone else.

we turned it on by default after only one transitionary release (the code was in 1.2.0) because we noticed that someone can craft a html email that they send to you which will be able to control your b2d Docker - and run any image they like - I doubt you'd want that either :)

This is all made even more frustrating by the fact that I was the main development resource Jan-Sept, and I only worked on it part time. We've since handed over development to @tianon and his team, so I can get back to the Docker support needs - so I'm hoping things will be able to be looked at earlier in the release cycle.

yup, compatibility and communication of deprecations is hard :)

[buuhsmead]

Made a asciicast https://asciinema.org/a/13542 to show how to disable TLS in 1.3.1 on OSX.

[detro]

@buuhsmead thanks for that

[RichardHightower]

docker run -d -p 2375:2375 --volume=/var/run/docker.sock:/var/run/docker.sock --name=docker-http sequenceiq/socat

Fixes problem for me and we tried every damn thing. That works.