Hey,
How does Istio mTLS behave when two workloads communicating with each other are already using mTLS?
Let’s say that we borught into the mesh couple of services that share the same root certs, have genearated private keys, and self signed certs - basically old school mTLS backbone. Beside of that, in mesh reside few other services that serves plaintext. We decided to wrap all of them into one service mesh to enforce encypted traffic (STRICT PeerAuthentication). It seems like all of the services can talk to each other and everything works well.
The question is how does Istio proxy handle inside mesh traffic, which is already encrypted?
Does it say - allright, this one is encrypted, I’ll let you through.
Or - I dont care wheather you’re encrypted or not I must direct you through my mTLS https tunnel (I don’t even know if this double encryption is possible)
Regards
Istio allows you to specify TLS mode on the client side. You can set
“ClientTLSSettings” in DestinationRule to “mode: MUTUAL” (instead of “ISTIO_MUTUAL”), and specify the workload cert, root cert, and private key. Istio / Destination Rule The service will then use your custom mTLS instead of the mTLS provided by Istio.
Thank you @liminwang
However, we still do not have answer what is the default Istio behaviour, without creating a DestinationRule at all and having strict PeerAuthentication.
Moreover, as I understand mode MUTUAL: it expects non encrypted traffic and uses certs and private key provided by me and pointed in configuration, to encrypt proxied traffic. Otherwise why would I need to specify certs and private key? To let Istio validate if the traffic was previously encrypted with given keys? It would not make much sense.
Here we have different situation. The application itself is sending mTLS encrypted traffic from the very begining. This is legacy application that can work only if certs and private key are provided at its accessible storage. There is no unencrypted traffic leaving the container. The question is if Istio allows encrypted traffic to pass thorugh, or if it uses ISTIO_MUTUAL to tunnel already mTLS encrypted connection.
We have this exact same problem. Our pod uses anonymous TLS at the application layer. It appears like when we try to initiate TLS from the application, even though we have strict TLS configured in Istio, the proxy passes our TLS connection through to the server side proxy. The server proxy then presents an istio certificate to the application which isn’t expecting certificates.