The use case:
We have a service that listens on port 443 with a self-signed certificate. Replacing this with Istio mTLS is not viable because clients external to the cluster/Istio mesh need to connect and both present a client certificate and verify the one served. Port 443 can also receive “browser” traffic, which does not require a client certificate.
Because Istio, at least as of 1.1.1, does not currently support mixed TLS-passthrough and terminating HTTPS on the same listener (0.0.0.0_443) even with different SNIs, if we connections using the “public” SNI to serve a browser-friendly certificate, it seems like we’re limited to the following options for now:
- Create a separate ingressgateway deployment/service for the second type of connection.
- Use TLS passthrough at the gateway for all incoming connections, pass them to some sort of proxy service running in the mesh that can either terminate TLS or do passthrough to the end service as needed. (haproxy maybe?)
Are there other options? What about using an EnvoyFilter on the ingressgateway with an sni_cluster match, either terminating and reconnecting via HTTPS SIMPLE or doing TLS PASSTHROUGH based on the SNI value? Is that a possibility?
This doesn’t have to be production-grade at this point, but it does need to work more or less. Eventually I’d hope Istio would just handle mixed TLS/HTTPS listeners natively.