Implementing Istio for mTLS is there any way to configure which TLS versions are supported? It appears that TLS 1.0 thru 1.3 are supported, but I need to be able to set the minimum version to TLS 1.2. Also, how do I test which versions are currently being used in my mesh? For example, if I’m running bookinfo demo with mTLS enabled?
I don’t believe we support configuring minimum TLS versions, although Envoy does support this, so it would be possible to support that config in the future.
Gateway object supports tls version modification, but sidecar does not support it. I try to use envoyfilter to modify sidecar outbound tls version, but failed, anyone can comment it?
i don’t think there’s a option for sidecar. reasonably to me to add at a mesh config global settings though.
to inspect the versoin, i think the openssl client connect has some dump info to show the version string.
i don’t think the minimal version make sense though. for mtls between sidecar, 95% cases both ends are envoy/istio workloads, offer min/max is too much details for the API.
let me know what you think, you can file or (find an exsting feature request to the github issue about supporting this) if above looks good to you.
@incfly, thanks for comments, I use sidecar to connect external server, and use sidecar to do mTLS (external) directly without egress gateway, that is why I need to modify the tls version in sidecar.
Another use case for configuring min/max in the sidecar is TLS passthrough mode with SNI routing in the ingress. In this case, it is the sidecar’s TLS context that determines the supported TLS versions that are sent in the ServerHello.
Secondly, it is also useful to scan servers and verify that only TLS 1.2 or higher is offered so that regardless of the client software, you can be sure you’ve met the requirement.
We’ve modified pkg/networking/core/v1alpha3/cluster.go and pkg/networking/core/v1alpha3/listener.go to explicitly configure the min/max TLS version and ciphers. We could draft a PR if you could suggest the config object best suited for the option.
This is envoy issue which summaried all TLS configuration supporting activities https://github.com/envoyproxy/envoy/issues/5401
The following show why envoy proxy does not support TLS 1.3 as client.
I can use envoyfilter to configure the TLS1.3 for sidecar now, but according to this issue, I can not use it.
I encounter a similar problem. I want to configure the TLS version with envoyfilter, but didn’t succeeded. I wrote the following envoyfilter, checked the config with istioctl proxy-config after creation of the pods and i can see my modifications, but not merged with the initial config. So it’s not taken into account.
Here is what my envoy filter looks like:
- applyTo: CLUSTER
match:
context: SIDECAR_OUTBOUND
patch:
operation: MERGE
value:
transport_socket_matches:
- name: "tlsMode-istio"
match:
tlsMode: "istio"
transport_socket:
name: "envoy.transport_sockets.tls"
typed_config:
"@type": "type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext"
common_tls_context:
tls_params:
tls_maximum_protocol_version: TLSv1_3
tls_minimum_protocol_version: TLSv1_3
Can someone tell me what am i doing wrong, or if it is even possible to do it this way? Thank you
I don’t think it is supported.
Try the following envoyfilter, and then check it by using istioctl
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: sidecar-tls-version
namespace: hobby
spec:
workloadSelector:
labels:
app: productpage
configPatches:
- applyTo: CLUSTER
match:
context: SIDECAR_OUTBOUND
cluster:
portNumber: 443
service: "www.google.com"
patch:
operation: MERGE
value:
transport_socket:
typed_config:
'@type': type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext
common_tls_context:
tls_params:
tls_maximum_protocol_version: TLSv1_3
tls_minimum_protocol_version: TLSv1_3
And then use command “istioctl pc cluster pod-name. --fqdn www.google.com -ojson” to check it.
I just check in my lab, even the tls1.3 configuration can goto sidecar, the tcpdump show it still try to use tls 1.2 handshake, and server response Alert (Level: Fatal, Description: Protocol Version)
So do you have found the correct way to use the envoy config filter
After more testing, I got some results now, it is a little bit complicated. :-（
- www.google.com, and www.facebook.com can work with TLS1.3 with envoyfilter + TLS origination.
- http2.pro need to add a fixing (envoy filter patch in https://github.com/istio/istio/issues/24619) before it can work for http2.pro can not realize the istio* alpn name. Case 1 also has this problem, but seems the google/facebook can handle it.
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: google-com
namespace: hobby
spec:
hosts:
- www.google.com
location: MESH_EXTERNAL
ports:
- name: http-port-for-tls-origination
number: 443
protocol: HTTP
resolution: NONE
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: google-com
namespace: hobby
spec:
host: www.google.com
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: SIMPLE
---
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: goole-com
namespace: hobby
spec:
configPatches:
- applyTo: CLUSTER
match:
cluster:
portNumber: 443
service: www.google.com
context: SIDECAR_OUTBOUND
patch:
operation: MERGE
value:
transport_socket:
typed_config:
'@type': type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext
common_tls_context:
tls_params:
tls_maximum_protocol_version: TLSv1_3
tls_minimum_protocol_version: TLSv1_3
workloadSelector:
labels:
app: sleep # modify this for your pod
any comment is welcome
My latest result is the TLS1.3 configuration can work also for client side, not problems found until now, if any of you has problems, we can discuss more detail.