Shriram Sharma
Shriram Sharma
@alexdotsh , can you please resolve the CI failures? Thanks
TLS on sidecar proxy implementation always uses http1.1 even when ALPN negotiation during TLS has h2
It seems [HttpProtocolOptions.AutoHttpConfig](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/upstreams/http/v3/http_protocol_options.proto#extensions-upstreams-http-v3-httpprotocoloptions-autohttpconfig) is probably not the right away to go about fixing this. As the document mentions, this can only work with transport socker that supports `ALPN`, and in...
TLS on sidecar proxy implementation always uses http1.1 even when ALPN negotiation during TLS has h2
@howardjohn , I've been thinking about this today and it seems even `HttpProtocolOptions_UseDownstreamProtocolConfig` also might not be the correct approach to this. Since during ALPN negotiation, the server negotiates `h2`...
@kfaseela @howardjohn @hzxuzhonghu ... Here are some proposals we came up with. cc: @aattuluri ### Solution 1: Honor `PeerAuthentication` only for mTLS auth. If the sidecar config has TLS mode...
> Or can we move sidecar tls setting to PA? @hzxuzhonghu , yeah that's the `Solution 3` mentioned above but that brings in the issue of backward compatibility.
> For simplicity why cannot we make user-defined tls override istio tls? @hzxuzhonghu , I agree this would be the simplest approach. Basically TLS config on the sidecar takes precedence...
Thanks @howardjohn @hzxuzhonghu @kfaseela for your feedback. I'll bring this up in the next `Networking Group` meeting and see if we can get a good consensus on the solutions discussed...
It seems like moving the TLS config to `PeerAuthN` was not an acceptable solution as discussed here https://github.com/istio/api/pull/2314. As @howardjohn and @costinm mentioned, in the future we could either utilize...