crypto/tls: client auth failure alert codes can be improved

[anitgandhi]

What version of Go are you using (go version)?

$ go version
go version go1.18 darwin/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/agandhi/Library/Caches/go-build"
GOENV="/Users/agandhi/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/agandhi/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/agandhi/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/agandhi/.gimme/versions/go1.18.darwin.amd64"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/agandhi/.gimme/versions/go1.18.darwin.amd64/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/8b/jm61yqyn0g126b4p23hrfz7c0000gp/T/go-build4159564691=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

1. Run a Go TLS server with ClientAuthType configuration higher than RequestClientCert. This could be an HTTPS server, gRPC, etc.
2. Connect to it using curl, openssl s_client, etc and provide an invalid client certificate.

What did you expect to see?

I'd like to see one of the more meaningful TLS alerts that RFC 5246 (TLSv1.2) or RFC 8446 (TLSv1.3) define. Namely:

• certificate_required when the server is configured with tls.RequireAnyClientCert or tls.RequireAndVerifyClientCert, and the client doesn't provide any client cert
• certificate_expired when the client provides a client cert but it's expired (or not yet valid)
• unknown_ca when the client provides a client cert but it's not signed by an authority that the Go TLS server is configured to require.

What did you see instead?

TLS alert bad_certificate is always returned, which is often confusing to end users because it doesn't surface enough information to quickly find out if/how they can fix their client certificate.

[anitgandhi]

I actually have this fixed already in a fork of mine, you can view it here: master...anitgandhi:improve-client-auth-alerts
I've tested this locally and it's working well.

But, I wanted to just quickly have a discussion to here to ensure the maintainers are open to changing this behavior.
I tried to track down any older issues or git history to see if it was an explicit choice to just always use bad_certificate, or if it was mostly just an oversight.

If folks are open to fixing this, I'll be happy to open a PR/CL from my branch linked above.

Thanks in advance!

[anitgandhi]

Perhaps this requires a separate issue or discussion, but I would have also liked to take advantage of the certificate_revoked alert code.

I know crypto/tls nor crypto/x509.Verify does not directly do any CRL checking; however, I was considering a special case such that if VerifyPeerCertificate is not nil, and it returns a known/sentinel error indicating revocation, then crypto/tls would use the certificate_revoked alert code.

I imagine the sentinel error part could be done by extending the existing crypto/x509.CertificateInvalidError by adding a new InvalidReason value like Revoked. Then, crypto/tls could just check the VerifyPeerCertificate returned err like so:

if c.config.VerifyPeerCertificate != nil {
	if err := c.config.VerifyPeerCertificate(certificates, c.verifiedChains); err != nil {
		var errCertificateInvalid x509.CertificateInvalidError
		var alert alert
		if errors.As(err, &errCertificateInvalid) && errCertificateInvalid.Reason == x509.Revoked {
			alert = alertCertificateRevoked
		} else {
			alert = alertBadCertificate
		}
		c.sendAlert(alert)
		return err
	}
}

[anitgandhi]

/cc @FiloSottile

[cherrymui]

cc @rolandshoemaker @kevinburke

[anitgandhi]

sorry for the ping on this folks, any thoughts? i wanted to try and get this in before the 1.19 dev freeze, if possible.

[ianlancetaylor]

CC @golang/security

[gopherbot]

Change https://go.dev/cl/410496 mentions this issue: crypto/tls: improve client auth failure alerts

[rolandshoemaker]

Hey, sorry for the lag. The main portion of this (returning the more specific alerts) seems reasonable. We're currently in the 1.19 freeze, so we'll have to wait for 1.20 to get this in (the tree should re-open in August.)

[anitgandhi]

@rolandshoemaker no problem, and sounds good. I went ahead and opened the CL; is it ok to just leave it as-is until August, or should I close it out?

[rolandshoemaker]

Yup leave it open and I'll give it a review, and once the tree opens we can submit it.

[anitgandhi]

Hi @rolandshoemaker , just a friendly ping on this/the CL now that the tree has been opened for 1.20. Thanks in advance!

[rolandshoemaker]

Sorry for the long wait, left a comment on the CL.

[anitgandhi]

@rolandshoemaker 👋 I've resolved the comment on the CL; any chance this could still make it in for 1.20?

[anitgandhi]

Hi @rolandshoemaker , Happy New Year!
Gentle ping on the above now that 1.20 RC2 is already out - is it still possible for this to make it in 1.20 (since it was reviewed and approved a couple months back)?

It would be a huge help for our organization when debugging mTLS errors

[gopherbot]

Change https://go.dev/cl/505436 mentions this issue: doc/go1.21: document changes in crypto/tls related to client authentication alerts