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
Labels
FrozenDueToAge Proposal Proposal-Crypto Proposal related to crypto packages or other security issues
Milestone

Comments

@loganaden
Copy link

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.

@bradfitz bradfitz added the Proposal-Crypto Proposal related to crypto packages or other security issues label Nov 20, 2018
@FiloSottile
Copy link
Contributor

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
@loganaden
Copy link
Author

@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
Copy link
Contributor

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.
Labels
FrozenDueToAge Proposal Proposal-Crypto Proposal related to crypto packages or other security issues
Projects
None yet
Development

No branches or pull requests

5 participants