istio: Not able to access any HTTPS external services using Istio

We have Istio cluster running on 1.1.6 and 1.1.4 We have similar issue on both the clusters that not able to access any external HTTPS url like Google. We do not have any Service Entry and mTLS is disabled cluster wise. There is no logs on the istio-proxy side car.

 curl https://www.google.com --verbose
* Rebuilt URL to: https://www.google.com/
*   Trying 172.217.6.68...
* TCP_NODELAY set
* Connected to www.google.com (172.217.6.68) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

Where should we look for some debug information. Any help on this would be great

We run Kuberenetes v1.13.2 with Weavenet CNI

We have this issue only with pods that have istio sidecar

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 2
  • Comments: 20 (4 by maintainers)

Most upvoted comments

@anoopl Had the same issue, HTTP service was created for port 443 in some other namespace which caused all https calls to external services to fail. Fixed it by changing the offending service.

I was able to get the proxy-config route working on another cluster. I found the issue as same as discussed here. https://discuss.istio.io/t/serviceentry-for-https-on-httpbin-org-resulting-in-connect-cr-srvr-hello-using-curl/2044/3

When i do : istioctl -n ist-stg-duck-stg proxy-config routes sleep-754684654f-bnffk.<namespace> --name 443 -o json It showed VirtualHosts to other 3 services like:

    {
        "name": "443",
        "virtualHosts": [
            {
                "name": "svc1.svc.cluster.local:443",

On checking this services we found that this services using name HTTP for 443 port like:

  clusterIP: xx.xx.xx.xx
  ports:
  - name: http
    port: 443
    protocol: TCP
    targetPort: 443

I renamed it to HTTPS and checked the route which showed:

    {
        "name": "443",
        "virtualHosts": [
            {
                "name": "allow_any",
                "domains": [
                    "*"
                ],
                "routes": [
                    {
                        "match": {
                            "prefix": "/"
                        },
                        "route": {
                            "cluster": "PassthroughCluster"
                        },
                        "perFilterConfig": {
                            "mixer": {
                                "disable_check_calls": true,
                                "forward_attributes": {
                                    "attributes": {}
                                },
                                "mixer_attributes": {
                                    "attributes": {}
                                }
                            }
                        }
                    }
                ]
            }
        ],
        "validateClusters": false
    }
]

After this curl https://www.google.com worked all like expected.

We have not enabled istio on this namespace. We do not know the reason for this bug. We are glad that at least we have a work around. However this can happen again if some of our client deploys a service with name HTTP for 443.

Thanks @chr15murray helping me on debugging this. Thanks to everyone.

I’ve been having the same issue and finally resolved it today with help from this link… https://discuss.istio.io/t/serviceentry-for-https-on-httpbin-org-resulting-in-connect-cr-srvr-hello-using-curl/2044/3

For me, I was deploying a dedicated ingress gateway for my application and as part of that I added a port called ‘http-port443’. This in tern was creating a service (as part of the ingress deployment) and I then hit the same problem described in the above link. My fix was to rename the port to ‘https-port443’ and now egress is working correctly.

Please also see here for an alternative workaround: https://github.com/istio/istio/issues/13914#issuecomment-490752299

This leads me to think that the problem is with how the sidecar forwards https traffic to the egress but I don’t know enough about this to dig deeper and confirm if this is a bug or not.

Hope this helps

Thanks for the messages, we encountered the same issue (running on 1.1.5) and fixed it with this solution.

I see the issue is closed but no reference to any PR or change. Does that mean it is an expected behaviour of Istio? Or a bug? If a bug, has this been fixed in later versions?

I am still experiencing this issue on version 1.12.0 😞