cl-dataplane: Disable controlplane TLS session keys #364
Conversation
cmd/cl-dataplane/app/envoyconf.go
Outdated
| @@ -92,6 +92,7 @@ static_resources: | |||
| typed_config: | |||
| "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext | |||
| sni: {{.controlplaneGRPCSNI}} | |||
| max_session_keys: 0 | |||
There was a problem hiding this comment.
It would be better to have TODO remove it after the SNI proxy is removed, or maybe explain why you put it in the code.
|
Interesting, Thanks for the quick fix. Was this config changed recently which made envoy unstable? |
Just to be clear, this is not a bug in envoy, nor an envoy mis-configuration. In this case, envoy is the TLS client, and our cl-controlplane is the TLS server. The workaround fix of this PR is to configure envoy to disable the use of such large client hello packets, by disabling the "TLS session resume" feature (setting I don't know why we have not seen this error so far. Perhaps only in certain setups envoy decides to use this defaultly-enabled TLS-sessions feature. |
|
Opened up a PR (and issue) to fix the bug in tcpproxy: |
This commit disables envoy from using TLS session keys when connecting to the controlplane. Enabling session keys produces big TLS client hello packets, which cause a "buffer full" error on the controlplane's SNI proxy. Signed-off-by: Or Ozeri <[email protected]>
This PR disables envoy from using TLS session keys when connecting to the controlplane.
Enabling session keys produces big TLS client hello packets, which cause a "buffer full" error on the controlplane's SNI proxy.