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

crypto/tls: provide a way to dynamically handle client hellos #15699

Closed
danp opened this issue May 16, 2016 · 6 comments
Closed

crypto/tls: provide a way to dynamically handle client hellos #15699

danp opened this issue May 16, 2016 · 6 comments
Labels
FeatureRequest FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@danp
Copy link
Contributor

danp commented May 16, 2016

I'd like to control whether or not to offer the "h2" protocol during TLS handshake based on the client's requested server name. Currently there's no way to do this with crypto/tls.

Would an optional callback similar to GetCertificate be useful for this and other similar cases?

@danp
Copy link
Contributor Author

danp commented May 16, 2016

Erlang's ssl module has a similar facility: sni_fun in server-side ssl options, though it's only called when SNI is used. A callback that's used regardless of SNI (as GetCertificate is now) would be more generally useful.

@bradfitz bradfitz added this to the Go1.8Maybe milestone May 16, 2016
@bradfitz
Copy link
Contributor

To @agl for thoughts. (Not necessarily for implementation)

@danp
Copy link
Contributor Author

danp commented Jun 30, 2016

@agl this is something I'd really like to help implement or at least see for 1.8. Any input on this and/or #15707?

I'm roughly thinking of something like tls.Config.GetClientConfig(*tls.ClientHelloInfo) (*tls.Config, error) with more info on tls.ClientHelloInfo, such as ALPN protos. Select items on the returned config would be used for the connection. This hook would be called here or so.

@agl
Copy link
Contributor

agl commented Jul 5, 2016

It's on my desiderata list for 1.8.

@bradfitz
Copy link
Contributor

See #16066 for a related issue and my comment #16066 (comment) for one idea.

@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 10, 2016
@gopherbot
Copy link
Contributor

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

@golang golang locked and limited conversation to collaborators Oct 18, 2017
FiloSottile pushed a commit to FiloSottile/go that referenced this issue Oct 12, 2018
GetConfigForClient allows the tls.Config to be updated on a per-client
basis.

Fixes golang#16066.
Fixes golang#15707.
Fixes golang#15699.

Change-Id: I2c675a443d557f969441226729f98502b38901ea
Reviewed-on: https://go-review.googlesource.com/30790
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
FiloSottile pushed a commit to FiloSottile/go that referenced this issue Oct 12, 2018
GetConfigForClient allows the tls.Config to be updated on a per-client
basis.

Fixes golang#16066.
Fixes golang#15707.
Fixes golang#15699.

Change-Id: I2c675a443d557f969441226729f98502b38901ea
Reviewed-on: https://go-review.googlesource.com/30790
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@rsc rsc unassigned agl Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FeatureRequest FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants