关于Istio mTLS流量流程的疑问：Bookinginfo示例中HTTP调用困惑

Great question—this is one of the most common points of confusion when first working with Istio's mTLS, and it all boils down to how Istio's sidecar proxies handle traffic transparently. Let's break this down step by step:

1. Services use HTTP because they don't need to know about mTLS #

Istio's mTLS is designed to be completely transparent to your application code. When you enable mTLS in the mesh, your services don't need to be modified to send HTTPS requests—they can continue making regular HTTP calls to other service names (like http://details:9080 in Bookinfo).

This works because Istio configures the sidecar Envoy proxies to intercept all outbound traffic from your service. The service thinks it's talking directly to the target service, but it's actually sending HTTP traffic to its local Envoy proxy.

2. Envoy proxies handle the encryption/decryption #

Here's the critical flow that happens behind the scenes:

• Your service sends an HTTP request to the target service's DNS name/IP.
• The local Envoy (sidecar next to your service) intercepts this HTTP request, encrypts it using mTLS (converting it to HTTPS traffic), and sends it to the target service's Envoy proxy.
• The target Envoy receives the encrypted HTTPS traffic, decrypts it back to the original HTTP request, and then forwards that plain HTTP request to the actual backend service.

So the traffic between Envoy proxies is fully encrypted with mTLS, but the communication between each Envoy and its local service remains plain HTTP. That's why you don't see your services using HTTPS directly.

3. Why you see HTTP logs in the server-side Envoy #

The HTTP logs you're seeing in the server-side Envoy are for the decrypted traffic that's being forwarded to the backend service. Envoy logs the request after it's been decrypted, right before it sends it to the service container.

If you want to verify that the traffic between Envoys is encrypted, you can:

• Check Envoy's access logs for TLS-related fields (like tls_version, tls_cipher, or peer_certificate_issuer)—these will confirm that mTLS was used for the inter-Envoy communication.
• Use tcpdump to capture traffic on the Envoy-to-Envoy ports (usually 15006 for inbound mTLS traffic) and you'll see encrypted TLS packets instead of plain HTTP.

Example from Bookinfo #

Take the productpage service calling the details service:

1. productpage sends GET http://details:9080/details/0 as plain HTTP.
2. productpage's Envoy intercepts this, encrypts it to HTTPS, and sends it to details' Envoy.
3. details' Envoy decrypts the HTTPS traffic back to the original HTTP request, logs it, then forwards it to the details service over plain HTTP.
4. details service responds with plain HTTP, which details' Envoy encrypts and sends back to productpage's Envoy, which decrypts and forwards to productpage.

All the inter-service traffic across the mesh is encrypted, but your services never have to deal with TLS configuration or HTTPS calls.

内容的提问来源于stack exchange，提问作者user1138406