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 an API to allow registering custom TLS extensions #25807

Closed
kriskwiatkowski opened this issue Jun 9, 2018 · 2 comments
Labels
FrozenDueToAge Proposal Proposal-Crypto Proposal related to crypto packages or other security issues
Milestone

Comments

@kriskwiatkowski
Copy link

kriskwiatkowski commented Jun 9, 2018

The TLS protocol includes several points of extensibility, including list of TLS extensions. The values in these lists identify implementation capabilities. TLS follows a model where one side, usually the client, advertises capabilities and the peer, usually the server, selects them.

Currently support for TLS extensions is implemented in handshake_messages.go. Each extension has it's marshaling/unmarshaling code implemented as case in some switch statement.

Problem with this approach is that (i) adding new extensions requires code changes in crypto/tls and (ii) extension handling is implemented in big switch-case statement, which tend to be hard to maintain. Also marshaling/unmarshalng maybe could take advantage of "encoding/binary" package, instead of fiddling with bytes.

I would like to evaluate an idea of an API that allows users of "crypto/tls" to register theirs own implementation of TLS extensions. This would be useful for rarely used TLS extensions or those ones which are in kind of "draft" phase. From one hand - it would be good to have a possibility of supporting them to some extend, from the other hand Go team wouldn't need to maintain them.
It could be also good chance to refactor code that's handling extension marshaling/unmarshaling.

Idea would be to provide similar code that's already available in boringssl (see struct tls_extension in t1_lib.cc and "custom extensions" in custom_extensions.cc), which seems to be quite clear and simple.

I'm not sure yet what are downsides of such code. Thoughts?

@odeke-em odeke-em changed the title crypto/tls: Custom TLS extensions proposal: crypto/tls: add an API to allow registering custom TLS extensions Jun 11, 2018
@gopherbot gopherbot added this to the Proposal milestone Jun 11, 2018
@odeke-em
Copy link
Member

Thank you @henrydcase for the proposal. I'll page some folks who might be able to help out with this
/cc @FiloSottile @bradfitz @agl @rsc

@ianlancetaylor ianlancetaylor added the Proposal-Crypto Proposal related to crypto packages or other security issues label Jun 18, 2018
@kriskwiatkowski
Copy link
Author

after getting some opinions from authors of other tls libraries I dont want to propose this api anymore

@golang golang locked and limited conversation to collaborators Jul 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge Proposal Proposal-Crypto Proposal related to crypto packages or other security issues
Projects
None yet
Development

No branches or pull requests

4 participants