SSL issue with Istio enabled microservice using EgressRules. SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number

[Dadabhvai-Kashyap]

Is this a BUG or FEATURE REQUEST?: I think it is a bug Did you review istio.io/help and existing issues to identify if this is already solved or being worked on?: yes, no solved Bug: Y

What Version of Istio and Kubernetes are you using, where did you get Istio from, Installation details

istioctl version

GitRevision: 24089ea97c8d244493c93b499a666ddf4010b547-dirty
GitBranch: 6401744b90b43901b2aa4a8bced33c7bd54ffc13
User: root@cc5c34bbd1ee
GolangVersion: go1.8

kubectl version

Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.6+a08f5eeb62", GitCommit:"c84beff", GitTreeState:"clean", BuildDate:"2017-12-06T20:03:39Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

Is Istio Auth enabled or not ? Did you install istio.yaml, istio-auth.yaml.... istio.yaml - no mutual tls

What happened: I using egressRules

cat <<EOF | ./istioctl create -f -
apiVersion: config.istio.io/v1alpha2
kind: EgressRule
metadata:
  name: nodeapp-egress-rule
spec:
  destination:
    service: nodeapp.mydomain.in
  ports:
    - port: 3000
      protocol: https
EOF

Istio enabled NodeJs app fails to establish https connection to resource outside cluster using https SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:827:\n"} Same for the curl curl: (35) error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number What you expected to happen: Retrieve correct result How to reproduce it: Install sample software, inject side-car and try to request external https resource

[vadimeisenbergibm]

@Dadabhvai-Kashyap Please note that the app must issue an HTTP request to nodeapp.mydomain.in:3000. The Istio sidecar proxy (Envoy) will open HTTPS connection to nodeapp.mydomain.in:3000.

To read more about it - see https://istio.io/blog/2018/egress-https.html#tls-origination-by-istio.

[Dadabhvai-Kashyap]

@vadimeisenbergibm Is there any plans in the roadmap, to enable https request and make this more transparent in future? For now it looks like a workaround and not a production-ready feature

[vadimeisenbergibm]

@Dadabhvai-Kashyap We are considering various options. I would like to hear your feedback - what would be your expectation - how would you like Istio to handle it? If the application opens an HTTPS connection, the Envoy can only see opaque TCP (everything is encrypted), plus maybe SNI. We plan to support routing based on SNI, depending on https://github.com/envoyproxy/envoy/issues/1843.

Note that if the application will issue an HTTPS request, Istio will not have any HTTP information, except for SNI. So no headers, paths, methods, content in reports and in policy checks. So the support for HTTPS traffic originated by the application will be reduced, unless we use TLS interception. TLS interception would require us to inject somehow Istio root certificate into the applications, so the applications will trust certificates generated by Envoy.

[kevinohara80]

I just got bit with this today. A client library we’re using for jwks is expecting an https endpoint. Setting it to http breaks it. I think there has to be a lot of client libraries out there that are like this.

I’m curious what the proposals are for addressing this?

[vadimeisenbergibm]

You can set a TCP egress rule for that, see https://istio.io/docs/tasks/traffic-management/egress-tcp.html.

[kirgene]

Please, add SNI-based routing without TLS termination for ServiceEntry, HAProxy has this feature. Some applications have hardcoded HTTPS URLs like https://www.example.com in their code so there is no way to change it to HTTP. TCP rules are definitely not an option for production use: I don't want to track IP changes for services I use in 24/7 mode to prevent downtimes. I want to use stable domain names.

[vadimeisenbergibm]

@kirgene we are aware of it, we plan to add support for SNI-based routing once this feature is supported by Envoy.

[kichristensen]

@vadimeisenbergibm Is it correct that this has been added in https://github.com/envoyproxy/envoy/pull/3217? I know it has not been released, but just to update this issue.

[vadimeisenbergibm]

@kichristensen The SNI-based routing was added to Istio a week ago, I did not yet try it.

[vadimeisenbergibm]

@kichristensen @kirgene @Dadabhvai-Kashyap Note that Istio 0.8.0 supports HTTPS (originated by the application), no requirement to use HTTP anymore, see the second example in https://istio.io/docs/tasks/traffic-management/egress/#configuring-the-external-services .

[yantang-msft]

@vadimeisenbergibm Just want to confirm by 'support' it means routing based on SNI without HTTPS termination, correct? Is there any investigation/conclusion around injecting the istio root certificate to the application? How feasible is that?

[vadimeisenbergibm]

@yantang-msft

routing based on SNI without HTTPS termination

Correct.

Is there any investigation/conclusion around injecting the istio root certificate to the application? How feasible is that?

Here is a related issue https://github.com/istio/istio/issues/6355, see links to a discussion and a design document. You are welcome to provide your feedback.