Skip to content
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 · 7 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Proposal Proposal-Hold
Milestone

Comments

@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
@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
Copy link
Contributor

bcmills commented Feb 7, 2019

CC @bradfitz @FiloSottile @jayconrod

@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 7, 2019
@FiloSottile
Copy link
Contributor

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
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
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.

@phifty
Copy link

phifty commented Jan 24, 2020

It would be very useful for us to be able to pass a client certificate to the go tool. I guess this issue is different from #26232, because no text/html is transmitted without an tls handshake. So it cannot be fixed by extending to access-denied page.
I agree with @dmitris to keep the number of local tools small and would argument that if an -insecure flag exists, a -client-cert (or a matching environment variable) would be valid.
I'm looking forward to see updates on this and let me know if I can help in some way.

@daoleno
Copy link

daoleno commented Jun 1, 2020

There is a temporary solution. I use a MITM tool to provide client certificates.
Like this:

mitmdump --listen-host ${ip_address} --listen-port ${port} --ignore-hosts=${whitelist} --set client_certs=${cert}

And set

go env -w GOPRIVATE="your company repo"

@CodingMinds
Copy link

I'd really love to be able to use client certificates as well.
Any chance we get this implemented? I'd try to provide a pull request if there's any interest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Proposal Proposal-Hold
Projects
None yet
Development

No branches or pull requests

8 participants