proposal: Add GetClientCAs to tls.Config

[magiconair]

tls.Config provides a GetCertificate function for providing TLS certificates dynamically. I suggest to add a GetClientCAs function to provide the same for the ClientCAs field.

Rationale: On a server the ClientCAs field is used for client certificate authentication but to my knowledge it isn't possible to extend the list of client certificates at runtime without interruption of existing connections (restart service or listener) since x509.CertPool is a struct and not safe for use by multiple go routines. A GetClientCAs function would also mirror the GetCertificate function.

I have written a reverse proxy http://github.com/eBay/fabio for which I've added the dynamic reloading of TLS certificates without restart and would like to provide the same functionality for the client cert authentication.

I'm willing to write the change if this is something that could be accepted. Target would be Go 1.8 obviously.

[ianlancetaylor]

CC @agl

[bradfitz]

Ping @agl.

[magiconair]

FWIW, I've implemented the patch yesterday to see how difficult it would be and it looks like it is simple. In essence, I've added a GetClientCAs func() *x509.CertPool function to tls.Config and updated clone(), the handshake, the test and api/next.txt. ~20 lines with comments. The question remains whether this is the right approach.

[bradfitz]

You need tests too, which I imagine will be more than 20 lines.

[magiconair]

True. So far I've only updated the clone() test. But I could factor the new decision logic out into a separate function and write a simple test for that instead of writing a full integration test. Not sure what the preferred approach is.

[bradfitz]

You'll probably want something closer to an integration test than a single unit test. For things like this, it's too easy for a unit test to be misleading.

[magiconair]

OK, so far I was not successful finding a test for the ClientCAs field and its current behavior in the server handshake which I could mimic/enhance but I'll keep digging. Otherwise, I'll create one.

[magiconair]

@bradfitz Is there a way to run a specific test with go tool dist test ? Right now I'm running go tool dist test -v go_test:crypto/tls to run the entire crypto/tls suite but I'd like to run only my TestClientCAs test if possible.

Also, how can I provide the -update parameter as suggested in crypto/tls/handshake_test.go? Working around this by setting the default to true for now.

[bradfitz]

The same way as normal Go tests:

$ go test -v -run=YourNewTest crypto/tls

[magiconair]

Works - of course ... I was using go from another go1.7 directory which then failed :/

Thx for the quick reply.

[magiconair]

OK, so I have a patch with the changes and a full integration test which is an addition to the existing tests. This involved adding a new option to generate_cert.go to create a cert which contains x509.ExtKeyUsageClientAuth and replacing the test certificates in handshake_server_test.go since the new test needs to verify the client certificate and the old test certificates do not support that. Since I'm not a crypto expert a review would be nice :)

The tests check three cases:

• Only ClientCAs
• Only GetClientCAs()
• Prefer GetClientCAs() over ClientCAs

I've generated the updated testdata/* files with the homebrew version OpenSSL 1.0.2h 3 May 2016 of openssl on OSX but I don't imagine that this is the reference implementation that the crytpo/tls test refers to.

@bradfitz @agl How do we proceed?