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: TLS 1.3 API to disable middlebox compatibility mode #28890

Closed
loganaden opened this issue Nov 20, 2018 · 3 comments
Closed

proposal: crypto/tls: TLS 1.3 API to disable middlebox compatibility mode #28890

loganaden opened this issue Nov 20, 2018 · 3 comments

Comments

@loganaden
Copy link

@loganaden loganaden commented Nov 20, 2018

OpenSSL has a way to disable the middlebox compat mode in TLS 1.3.
SSL_OP_ENABLE_MIDDLEBOX_COMPAT
If set then dummy Change Cipher Spec (CCS) messages are sent in TLSv1.3. This has the effect of making TLSv1.3 look more like TLSv1.2 so that middleboxes that do not understand TLSv1.3 will not drop the connection. Regardless of whether this option is set or not CCS messages received from the peer will always be ignored in TLSv1.3. This option is set by default. To switch it off use SSL_clear_options().

Such an API would be useful in golang. I've been working on a patch.

@FiloSottile

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented Nov 23, 2018

Can you elaborate on why you need to turn this off? Servers are required to be compatible with it, and it costs 5 bytes, which does not seem nearly worth a configuration option.

@FiloSottile FiloSottile changed the title crypto/tls: TLS 1.3 API to disable middlebox compatibility mode proposal: crypto/tls: TLS 1.3 API to disable middlebox compatibility mode Nov 23, 2018
@gopherbot gopherbot added this to the Proposal milestone Nov 23, 2018
@gopherbot gopherbot added the Proposal label Nov 23, 2018
@loganaden

This comment has been minimized.

Copy link
Author

@loganaden loganaden commented Nov 23, 2018

@FiloSottile I agree with you. However, I don't see the point of sending a dummy CCS if there are no broken middleboxes along the path. Also I want to detect failing middleboxes before making a purchasing decision. If a middlebox doesn't work according to specs, the vendor won't get our money.

@FiloSottile

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented Nov 23, 2018

I agree with the vendor testing use case, but crypto/tls is meant for production use, not security or conformance testing. There are a number of forks that add all sorts of useful switches for that purpose.

Given it's basically free, I'd rather always send it (even when it's useless) than add the complexity and API surface to make it configurable. One of the main features of crypto/tls is that it's opinionated on anything it can reasonably decide for the user, and tls.Config is already more overwhelming than I'd like it to be.

@golang golang locked and limited conversation to collaborators Nov 23, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.