Joe Khoobyar
Joe Khoobyar

Reputation: 1

How can I disable SNI for a Gateway API gateway implemented by Istio?

I have an ingress gateway using the kubernetes Gateway API as implemented by Istio. I need to disable SNI, because the initial TLS connection is a downstream load balancer which does not pass through SNI. The load balancer also will not pass through the TLS connection either.

I don't see any option for disabling SNI when using the Gateway API - so I have tried using envoy filters to automatically set the SNI from the HTTP host headers. It looks like I'm not able to get the envoy filters to patch the gateway traffic.

I have this gateway:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: foo-dev
  namespace: istio-ingress
  labels:
    istio.io/gateway-name: foo-dev
  annotations:
    networking.istio.io/service-type: ClusterIP
spec:
  gatewayClassName: istio
  listeners:
    - name: default
      port: 80
      protocol: HTTP
      hostname: "*.example.com"
      allowedRoutes:
        kinds:
          - kind: HTTPRoute
        namespaces:
          from: Selector
          selector:
            matchLabels:
              kubernetes.io/metadata.name: foo
    - name: tls
      port: 443
      protocol: HTTPS
      hostname: "*.example.com"
      tls:
        certificateRefs:
          - name: foo-dev-tls
      allowedRoutes:
        kinds:
          - kind: HTTPRoute
        namespaces:
          from: Selector
          selector:
           matchLabels:
             kubernetes.io/metadata.name: foo

I have this HTTPRoute:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: foo
  namespace: foo
spec:
  parentRefs:
    - name: foo-dev
      namespace: istio-ingress
  hostnames: ["dev-foo.example.com"]
  rules:
    - matches:
      - path:
          type: PathPrefix
          value: /
      backendRefs:
        - name: foo
          port: 443

And I have defined this filter (which doesn't work):

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: gateway-auto-sni-san-validation
  namespace: istio-ingress
spec:
  targetRefs:
    - name: foo-dev
      kind: Gateway
      group: gateway.networking.k8s.io
  configPatches:
    - applyTo: NETWORK_FILTER
      match:
        context: GATEWAY
      patch:
        operation: MERGE
        value:
# attempt 1
          upstream_http_protocol_options:
            auto_sni: true
            auto_san_validation: true
## attempt 2
#          typed_config:
#            "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.UpstreamHttpProtocolOptions"
#            common_http_protocol_options:
#              auto_sni: true
#              auto_san_validation: true
## attempt 3
#          typed_extension_protocol_options:
#            envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
#              "@type": "type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions"
#              upstream_http_protocol_options:
#                auto_sni: true
#                auto_san_validation: true

I expect that, when connecting to the gateway from inside the cluster, all I will need is the Host header to reach my workload.

However, this doesn't work:

$ curl -ivvk https://foo-dev-istio/api/health  -H 'Host: dev-foo.example.com'
*   Trying 172.20.88.10:443...
* Connected to foo-dev-istio (172.20.88.10) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: Connection reset by peer in connection to foo-dev-istio:443 
* Closing connection 0
* TLSv1.0 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, decode error (562):
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to foo-dev-istio:443 

Instead, I have to use supply SNI in order to get the traffic through:

$ curl -ivvk --resolve dev-foo.example.com:443:172.20.88.10 https://dev-foo.example.com/api/health  -H 'Host: dev-foo.example.com'
* Added dev-foo.example.com:443:172.20.88.10 to DNS cache
* Hostname dev-foo.example.com was found in DNS cache
*   Trying 172.20.88.10:443...
* Connected to dev-foo.example.com (172.20.88.10) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: O=Example, Inc.; CN=example.com
*  start date: Aug  9 14:14:50 2024 GMT
*  expire date: Aug  8 14:14:50 2029 GMT
*  issuer: O=Example, Inc.; CN=example.com
*  SSL certificate verify result: self-signed certificate (18), continuing anyway.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x556b874fee90)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET /api/health HTTP/2
> Host: dev-foo.example.com
> user-agent: curl/7.81.0
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 2147483647)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 200 
HTTP/2 200 
< x-powered-by: Express
x-powered-by: Express
< vary: Origin
vary: Origin
< access-control-allow-credentials: true
access-control-allow-credentials: true
< content-type: application/json; charset=utf-8
content-type: application/json; charset=utf-8
< content-length: 95
content-length: 95
< date: Fri, 09 Aug 2024 16:13:59 GMT
date: Fri, 09 Aug 2024 16:13:59 GMT
< x-envoy-upstream-service-time: 8
x-envoy-upstream-service-time: 8
< server: istio-envoy
server: istio-envoy

< 
* Connection #0 to host dev-foo.example.com left intact
{"status":"ok","info":{"cache":{"status":"up"}},"error":{},"details":{"cache":{"status":"up"}}}

Upvotes: 0

Views: 164

Answers (0)

Related Questions