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?
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/tlsand (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_extensionint1_lib.ccand "custom extensions" incustom_extensions.cc), which seems to be quite clear and simple.I'm not sure yet what are downsides of such code. Thoughts?