net/http: Allow verification of certificates beyond just hostname

[gopherbot]

by c@apcera.com:

What does 'go version' print?
go version devel +0449858880be Mon Aug 11 17:11:31 2014 -0400 darwin/amd64

What steps reproduce the problem?

1. Revoke a TLS certificate (for example, to mitigate Heartbleed)
2. Attempt to prevent a golang client from securing a connection using the revoked
certificate
3. Realize you can verify the hostname, but not other parts of the certificate prior to
establishing a connection and sending a request.

What happened?

Golang clients cannot currently be written to reject certificates based on factors other
than hostname.

What should have happened instead?

The certificate should be available to client code when establishing connections to
allow for more granular verification. The attached file is client code which could be
used to reject blacklisted certs if a hook were available in net/http.

Attachments:

1. certblacklist.go (932 bytes)

[gopherbot]

Comment 1:

CL https://golang.org/cl/128930043 mentions this issue.

[ianlancetaylor]

Comment 2:

Labels changed: added repo-main, release-none.

[bradfitz]

Comment 3:

I'll own getting this fixed one way or another, but copying Adam in case he has opinions
on where such a hook should live.
For instance, the CL above adds an HTTP-specific hook to check the
*tls.Conn+*tls.Config's suitability once it's already made.
Some alternatives as food for thought:
a)  not add a tls.Conn-checking hook in http but instead just add a DialTLS func
alongside net/http.Transport's Dial (http://golang.org/pkg/net/http/#Transport)
b) modify http://golang.org/pkg/crypto/tls/#Client to take policy in the Config, perhaps
as a func. Or add a Dialer type. (but that's basically the *Config struct).  Then the
user can just add the policy func to the existing net/http Transport's TLSClientConfig.
Is it better to have the policy/hook be in crypto/tls instead where maybe it can close
the connection more nicely, or check things earlier? I'm unsure.

Owner changed to @bradfitz.

Status changed to Accepted.

[gopherbot]

Comment 4 by c@apcera.com:

Would a)'s DialTLS be of the form func(network, addr string, cfg *tls.Config) (net.Conn,
error) ? I assume net/http would provide a default implementation that used
VerifyHostname internally? This approach seems viable.
b) is a direction I was leaning when thinking about possible cleaner implementations of
the above CL. I wasn't as clear on how to modify crypto/tls properly.

[philpennock]

Comment 5:

To me, as someone using the API, (b) makes more sense.  The people using the API aren't
changing how the layers interact, there should be no need to modify the code which the
HTTP layer uses to talk to the TLS layer.
In effect, we want to be able to set TLS policy; in this case, on whether or not to
accept an X.509 certificate; some parts of the policy are already available (chain back
to trust anchor; hostname to validate) others aren't.  This is no different from the TLS
verifications already available, except in not being available, so a callback made the
most sense.
The original PR/patch changed the "net/http".Transport but changing "crypto/tls".Config
instead lets us make the policy checks available to all TLS clients, not just HTTP and
is better, you're right.

[bradfitz]

Comment 6:

Adam: thoughts?

[gopherbot]

Comment 7 by ox@getlantern.org:

+1 on making this a policy option handled in crypto/tls, configured via something on
tls.Config.

[bradfitz]

Comment 8:

Sent out https://golang.org/cl/137940043 which I believe satisfies all the
needs.

[gopherbot]

Comment 9:

CL https://golang.org/cl/137940043 mentions this issue.

[gopherbot]

Comment 10 by c@apcera.com:

Brad: I wrote a test based on example_test.go in package tls. Attached here since
https://golang.org/cl/137940043 already has LGTM.

Attachments:

1. client_verify_test.patch.txt (1126 bytes)

[bradfitz]

Comment 11:

This issue was closed by revision ae47e04.

Status changed to Fixed.