Does Istio really can't perform filter HTTPS requests based on the destination domains?

8/8/2018

I've read this article about TLS Origination problem in istio. Let me quote it here:

There is a caveat to this story. In HTTPS, all the HTTP details (hostname, path, headers etc.) are encrypted, so Istio cannot know the destination domain of the encrypted requests. Well, Istio could know the destination domain by the SNI (Server Name Indication) field. This feature, however, is not yet implemented in Istio. Therefore, currently Istio cannot perform filtering of HTTPS requests based on the destination domains.

I want to understand, what does the bold statement really mean? Because, I've tried this:

  • Downloaded the istio-1.0.0 here to get the samples yaml code.

  • kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)


apiVersion: v1
kind: Service
metadata:
    name: sleep
    labels:
    app: sleep
spec:
    ports:
    - port: 80
    name: http
    selector:
    app: sleep
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
    name: sleep
spec:
    replicas: 1
    template:
    metadata:
        labels:
        app: sleep
    spec:
        containers:
        - name: sleep
        image: tutum/curl
        command: ["/bin/sleep","infinity"]
        imagePullPolicy: IfNotPresent
  • And apply this ServiceEntry

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
    name: cnn
spec:
    hosts:
    - "*.cnn.com"
    ports:
    - number: 80
    name: http-port
    protocol: HTTP
    - number: 443
    name: https-port
    protocol: HTTPS
    resolution: NONE
  • And exec this curl command inside the pod

export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
kubectl exec -it $SOURCE_POD -c sleep -- curl -s -o /dev/null -D - https://edition.cnn.com/politics
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
x-servedByHost: ::ffff:172.17.128.31
access-control-allow-origin: *
cache-control: max-age=60
content-security-policy: default-src 'self' blob: https://*.cnn.com:* http://*.cnn.com:* *.cnn.io:* *.cnn.net:* *.turner.com:* *.turner.io:* *.ugdturner.com:* courageousstudio.com *.vgtf.net:*; script-src 'unsafe-eval' 'unsafe-inline' 'self' *; style-src 'unsafe-inline' 'self' blob: *; child-src 'self' blob: *; frame-src 'self' *; object-src 'self' *; img-src 'self' data: blob: *; media-src 'self' data: blob: *; font-src 'self' data: *; connect-src 'self' *; frame-ancestors 'self' https://*.cnn.com:* http://*.cnn.com https://*.cnn.io:* http://*.cnn.io:* *.turner.com:* courageousstudio.com;
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
Via: 1.1 varnish
Content-Length: 1554561
Accept-Ranges: bytes
Date: Wed, 08 Aug 2018 04:59:07 GMT
Via: 1.1 varnish
Age: 105
Connection: keep-alive
Set-Cookie: countryCode=US; Domain=.cnn.com; Path=/
Set-Cookie: geoData=mountain view|CA|94043|US|NA; Domain=.cnn.com; Path=/
Set-Cookie: tryThing00=3860; Domain=.cnn.com; Path=/; Expires=Mon Jul 01 2019 00:00:00 GMT
Set-Cookie: tryThing01=4349; Domain=.cnn.com; Path=/; Expires=Fri Mar 01 2019 00:00:00 GMT
Set-Cookie: tryThing02=4896; Domain=.cnn.com; Path=/; Expires=Wed Jan 01 2020 00:00:00 GMT
X-Served-By: cache-iad2150-IAD, cache-sin18022-SIN
X-Cache: HIT, MISS
X-Cache-Hits: 1, 0
X-Timer: S1533704347.303019,VS0,VE299
Vary: Accept-Encoding

As you can see, I can access the edition.cnn.com with HTTPS (ssl) protocol. Am I misunderstand the bold statement meaning?

-- Agung Pratama
istio
kubernetes

2 Answers

8/8/2018

What you're showing here is an https connection/request, and that has no reason not to work. Filtering in this case means taking a specific action (ie. deny access) based on the destination Host in http terms (the one that makes hosting multiple sites on the same server IP possible) and that is what that statement refers to.

SNI is the way to identify what Host you're connecting to, before TLS connection is established.

-- Radek 'Goblin' Pieczonka
Source: StackOverflow

8/8/2018

The cited blog post is from January 31, 2018, and the statement was correct then. Now (1.0) Istio supports traffic routing by SNI, see https://istio.io/docs/tasks/traffic-management/egress/.

This reminds me to update that blog post, will do it by the end of this week. Sorry for the confusion, thank you for pointing to the issue.

-- Vadim Eisenberg
Source: StackOverflow