New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: cmd/go: enable mutual TLS authentication with client certificates in the go tool #30119

Open
dmitris opened this Issue Feb 7, 2019 · 4 comments

Comments

Projects
None yet
5 participants
@dmitris
Copy link
Contributor

dmitris commented Feb 7, 2019

It would be useful to be able to pass to the go tool a client TLS certificate + key + CAcert (in environment variables or otherwise) - especially, in environments that take Zero Trust Network (ZTN) seriously and where go tool needs to talk to the other side (the replace targets) that lives in a public cloud using mutual TLS for authN/Z. The "other side" can be either a GOPROXY server or a redirector (like golang.org) serving the meta tags. Since one of the ZTN principles is "every network connection must be authenticated and authorized", the question is how to implement it with the go tool and the requests it initiates.

Technically, it possibly comes down to how to pass desired TLS options (key/certificate/cacert filenames or such) to tls.Config that go would use when initiating connections.

@mikioh mikioh changed the title cmd:go: proposal - enable mutual TLS authentication with client certificates in the go tool proposal: cmd:go: enable mutual TLS authentication with client certificates in the go tool Feb 7, 2019

@gopherbot gopherbot added this to the Proposal milestone Feb 7, 2019

@gopherbot gopherbot added the Proposal label Feb 7, 2019

@bcmills bcmills changed the title proposal: cmd:go: enable mutual TLS authentication with client certificates in the go tool proposal: cmd/go: enable mutual TLS authentication with client certificates in the go tool Feb 7, 2019

@bcmills

This comment has been minimized.

Copy link
Member

bcmills commented Feb 7, 2019

@FiloSottile

This comment has been minimized.

Copy link
Member

FiloSottile commented Feb 7, 2019

I think the array of possible authentication schemes is too wide, so these should be handled by a local GOPROXY that exposes the unauthenticated protocol to the client, and does whatever authentication you want to the upstream.

I'm starting to think it would be nice to let GOPROXY be a binary that the go tool runs itself, so that a GOPROXY can be made even for small tasks, without having to run a network service on the local machine, which is a lot of friction.

@dmitris

This comment has been minimized.

Copy link
Contributor Author

dmitris commented Feb 7, 2019

I think a drawback of the local GOPROXY solution is that everyone running go who has to play the authentication game would need not just set some environment variables but would have to obtain / install / keep up-to-date, and make sure go can find and execute that separate program - in addition to setting an environment variable for GOPROXY. It also seems to open an additional security attack vector - at the least, you have to worry what kind of "interesting" compromises would become possible through the local GOPROXY binary. Personally for mTLS I would prefer to be able to tell go where to pick up cert/key/cacert from then deal with creating (?) / setting up additional binary.

@rsc

This comment has been minimized.

Copy link
Contributor

rsc commented Feb 13, 2019

Let's get the basic HTTP auth stuff working first (#26232) and then circle back to thinking about even more exotic authentication like TLS client certs.

@rsc rsc added the Proposal-Hold label Feb 13, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment