Minimum TLS version?

I’m trying to use the gateway TLS options as specified here:


Specifically, the minProtocolVersion and maxProtocolVersion, but it doesn’t seem to have any effect.
I’m running istio 1.4.4
Sample gateway:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: gateway-test
  namespace: istio-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - <something>/<something>
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      mode: PASSTHROUGH
      minProtocolVersion: TLSV1_2
      maxProtocolVersion: TLSV1_3

This does not seem to work. I can go into the istio-ingressgateway container, dump the envoy config (via curl localhost:15000/config_dump) and I’m not seeing any TLS protocol version configuration in the gateway configuration, nor in the target’s istio-proxy configuration. I am able to connect with TLSv1, TLSv1.1 or TLSv1.2. Obviously, I’d only like to connect with TLSv1.2 or higher.

I’m not seeing any obvious errors via kubectl logs on the containers either.

Suggestions? (Note: this question was also asked by someone else back in May 2019, and there were no responses.)

there’re some known issues about tls inspector, does not work with tls 1.3. we have a fix in 1.4.6. could you try to upgrade to 1.4.6 to see if this fix your problem?

@incfly I have installed istio 1.6 and with the below gateway settings and it seems that doesn’t work properly, because a run testssl and got this response

Testing protocols via sockets except NPN+ALPN

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    offered (deprecated)
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, http/1.1, grpc-exp (offered)

gateway.yaml

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  labels:
    operator.istio.io/component: IngressGateway
    operator.istio.io/managed: Reconcile
    operator.istio.io/version: 1.5.1
    release: istio
  name: default-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - REDACTED
      port:
        name: http
        number: 80
        protocol: http
      tls:
        httpsRedirect: true
    - hosts:
        - REDACTED
      port:
        name: https
        number: 443
        protocol: HTTPS
      tls:
        mode: SIMPLE
        minProtocolVersion: TLSV1_2
        maxProtocolVersion: TLSV1_3
        serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
        privateKey: /etc/istio/ingressgateway-certs/tls.key

I’m a bit confused.

Your gateway specifies min 1.2 max 1.3. which is matching what the testssl’s output,

 TLS 1.1    offered (deprecated)
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, http/1.1, grpc-exp (offered)

Do I miss anything?

With min = TLSv1.2 and max = TLSv1.3, TLS 1.1 should not even be offered.
The results should be closer to:

SSLv2      not offered (OK)
SSLv3      not offered (OK)
TLS 1      not offered
TLS 1.1    not offered
TLS 1.2    offered (OK)
TLS 1.3    offered (OK) : final
NPN/SPDY   not offered
ALPN/HTTP2 h2, http/1.1 (offered)

thats right @tshort, the result should appear like this:

TLS 1.1 not offered

Its seems that the gateway is ignoring the minProtocolVersion.

here is the stack overflow question.

@tshort i believe for passthrough mode the TLS is handled by app not istio. you can confirm this by simply changing it in the app side and check. or move the TLS certs to istio (SDS might be a good option).

@prabhu-mannu, agreed about the gateway. The Gateway configuration only applies to non-passthrough connections. We use SDS and “moving the TLS certs to istio” won’t fix the issue; TLS certs have no mechanism to limit the TLS version.

We have a non-trivial patch which modifies the JSON and other files to limit the TLS version and supported ciphers. Unfortunately, it is not amenable to easy configuration via YAML.

In fact, the testssl.sh output I provided was from our patched cluster.

If istio is handling the ssl termination (via SDS). you can set the minimum and maximum tls versions. I can confirm that it works, provided that the TLS mode is SIMPLE or MUTAL.
You can also define the supported cipherSuites (once supported by envoy) -> https://istio.io/latest/docs/reference/config/networking/gateway/#ServerTLSSettings-TLSmode
https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/auth/common.proto
your config should be something like this

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: gateway-test
      namespace: istio-gateway
    spec:
      selector:
        istio: ingressgateway
      servers:
      - hosts:
        - <something>/<something>
        port:
          name: https
          number: 443
          protocol: HTTPS
        tls:
          mode: SIMPLE
          credentialName: <k8s-tls-secert-name>
          minProtocolVersion: TLSV1_2
          maxProtocolVersion: TLSV1_3
          cipherSuites: <list of strings>

We are using PASSTHROUGH. The mechanism as described doesn’t work for that option.

I change my configuration in istio 1.6 like you propose, but I got the same result, server keep offer the 1.1

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  labels:
    operator.istio.io/component: IngressGateway
    operator.istio.io/managed: Reconcile
    operator.istio.io/version: 1.5.1
    release: istio
  name: default-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - <something>/<something>
      port:
        name: http
        number: 80
        protocol: http
      tls:
        httpsRedirect: true
    - hosts:
        - <something>/<something>
      port:
        name: https
        number: 443
        protocol: HTTPS
      tls:
        mode: SIMPLE
        minProtocolVersion: TLSV1_2
        maxProtocolVersion: TLSV1_3
        credentialName: ingressgateway-certs
        cipherSuites:
          - ECDHE-ECDSA-AES128-GCM-SHA256
          - ECDHE-RSA-AES128-GCM-SHA256
          - ECDHE-ECDSA-AES128-SHA
          - AES128-GCM-SHA256
          - AES128-SHA
          - ECDHE-ECDSA-AES256-GCM-SHA384
          - ECDHE-RSA-AES256-GCM-SHA384
          - ECDHE-ECDSA-AES256-SHA
          - AES256-GCM-SHA384
          - AES256-SHA

@tshort
you can only set the tls configs where the TLS is terminated


As per the above example ssl is terminated in the nginx pod (which is same case as yours), and only the nginx can set/control tls configs. Replace nginx with what ever tech stack/app you are using.

@framled can you check if the config is valid, also ensure that credentialName used is valid. i have not used 1.6 yet but i can assure that 1.2,1.3,1.4 this setting works fine.
i have not tried the cipherSuites yet.

Below is the extract of what i have my setup

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: someservice-dummy-provider02
  namespace: someservice-dev
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - someapi02.dev.someservice.example.net
    port:
      name: someapi02-https
      number: 443
      protocol: HTTPS
    tls:
      credentialName: someapi-ssl-dev
      minProtocolVersion: TLSV1_2
      maxProtocolVersion: TLSV1_3
      mode: SIMPLE

you can only set the tls configs where the TLS is terminated

@prabhu-mannu: Agreed, the problem is that we are using istio for local termination because we are not using SIMPLE, we are using PASSTHROUGH at the gateway and ISTIO_MUTUAL between pods.

Our nginx pod is actually fronted by the istio-proxy. We could replace nginx with anything, and that still wouldn’t solve our problem as the istio-proxy terminates TLS. We can’t configure the istio-proxy TLS termination, and THAT is the problem.

The fundamental problem is that istio DOES NOT provide support for configuring TLS within the istio-proxy containers EXCEPT for ingress-gateway termination, which does not work for the very common PASSTHROUGH configuration.

1 Like