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: crypto/tls: add GetConfigForServer callback to *tls.Config #22836

Open
nhooyr opened this Issue Nov 21, 2017 · 5 comments

Comments

Projects
None yet
7 participants
@nhooyr
Copy link
Contributor

nhooyr commented Nov 21, 2017

I'd like to be able to dynamically update a *tls.Config's RootCAs field to support changes in root CAs without having to restart the server.

If I want to update the ClientCAs field, I can easily do this by using the GetConfigForClient hook. Whereas for RootCAs, there is no such callback. Reason being that the ClientCAs field is used by servers and that is the only time GetConfigForClient is called. The RootCAs field is used only by clients.

My only option would be to create a *tls.Config structure that is protected by a mutex. For dialing, I would lock the mutex, grab the pointer and then unlock and use the Config normally. When the Config needs to be updated, I would clone the *tls.Config, update the cloned Config, lock the mutex, replace the pointer and then unlock.

I could easily abstract the above away into a function so this isn't a big issue but my code would be significantly more clean and symmetric across server and client if there was a callback to grab the Config for the connection dynamically as a client.

Of course, my use case is distinct from the use cases that gave rise to the callbacks, where the server/client wants to respond to the server/client dynamically. I just want to update the Config dynamically regardless of who the server/client is. So I suspect my use case may be a misuse of even the GetConfigForClient callback but it is in my opinion still the cleanest solution and makes it really easy to play with third party frameworks that do not expect the *tls.Config to be dynamically updated like gRPC.

@bradfitz suggested this in #16066 (comment) but it was never implemented.

@titanous titanous changed the title crypto/tls: add GetConfigForServer callback to *tls.Config proposal: crypto/tls: add GetConfigForServer callback to *tls.Config Dec 6, 2017

@gopherbot gopherbot added this to the Proposal milestone Dec 6, 2017

@gopherbot gopherbot added the Proposal label Dec 6, 2017

@titanous

This comment has been minimized.

Copy link
Member

titanous commented Dec 6, 2017

/cc @agl

@rsc

This comment has been minimized.

Copy link
Contributor

rsc commented Feb 5, 2018

@FiloSottile

This comment has been minimized.

Copy link
Member

FiloSottile commented Feb 5, 2018

GetConfigForClient turned out to be a simple and extremely powerful addition, enabling a number of advanced use cases without needing to expose a knob for each one. The latest example being #23679. (The only annoyance is how it plays with H/2, where you have to remember to configure it on the outer Config.)

So given how much of a success that API was, I'd be in favor of making the symmetric one on the client side.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

ianlancetaylor commented Mar 19, 2018

@agl @bradfitz Any thoughts on this?

@bradfitz

This comment has been minimized.

Copy link
Member

bradfitz commented Apr 2, 2018

I'm fine with it, but I'll defer to @agl and @FiloSottile for decision. They'd be the ones primarily impacted by any maintenance cost.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.