Theia cannot reach the API server with both TLS and proxy enabled

Describe the bug

When both TLS and http proxy are enabled, it seems that Theia cannot reach the Che server API endpoint by its external URL.

This becomes critical now that TLS is enabled by default to have webviews working.

This might be related to this Axios bug: https://github.com/axios/axios/issues/925#issuecomment-574617787

Che version

• latest
• nightly
• other: please specify

Steps to reproduce

1. Configure a Che server installation with a proxy and without TLS: Che-theia workspace should be able to start correctly (with webview problems though)
2. Configure a Che server installation with a proxy and with TLS: You should see some errors in the Che-theia logs and Che-theia would be able to fetch the workspace definition from the Che API server

Expected behavior

http proxy configuration should work even when TLS is enabled (which is the default case now)

Runtime

• kubernetes (include output of kubectl version)
• Openshift (include output of oc version)
• minikube (include output of minikube version and kubectl version)
• minishift (include output of minishift version and oc version)
• docker-desktop + K8S (include output of docker version and kubectl version)
• other: (please specify)

Installation method

• chectl
• che-operator
• minishift-addon
• I don’t know

Environment

• my computer
  • Windows
  • Linux
  • macOS
• Cloud
  • Amazon
  • Azure
  • GCE
  • other (please specify)
• other: please specify

Eclipse Che Logs

Additional context

This might be critical for CRW 2.1 and possibly to include into the 7.9.2 release

[davidfestal]

After a bunch of tests done with the axios library inside the che-theia container of a Che workspace running in a disconnected environment behind a proxy*, here is the current analysis of the problem: The error was coming from the fact that axios implementation of https requests through a http proxy is limited. In particular, it seems it doesn’t correctly use the CONNECT method that allows tunneling a https request inside a http proxy. A consequence of this is that the underlying socket connection opened to finally reach the target endpoint is not a ssl socket. This finally results in an error from the Proxy, especially with self-signed certificates.

The good news of this is that Axios is configurable / customizable enough, so that, when a https request needs a http proxy, we should be able to override the request config to change the httpsAgent and use one created by the tunnel module.

I already tested the tunnel module solution and was able to reach the Che API server through the proxy even with TLS and self-signed certificates.

I’ll further propose a PR to include this into the existing che-workspae-client package.

[disaster37]

Hi, I have started che 7.17.0 and I have the same matter when deploy it with tls and use enterprise proxy. All start right on kubernetes, and my browser access to teiga, but all is blank and nothing work.

How I can mitigate this ?

Best Regards