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

[dmitris]

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.

[bcmills]

CC @bradfitz @FiloSottile @jayconrod

[FiloSottile]

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]

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]

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]

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]

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"