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

[davidfestal]

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: axios/axios#925 (comment)

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]

One possible way to fix it might be to use the solution proposed here: axios/axios#925 (comment) in the che-workspace-client, in case https_proxy env variable is set and TLS mode is enabled (API URL starts with https)
cc @vinokurig

[davidfestal]

@dmytro-ndp @RickJWagner seemed to think it should be considered as a blocker for CRW 2.1

@rhopp @l0rd do you confirm ?

[rhopp]

I tend to agree... Running without tls or without proxy is imo no-go for lot of production environments.

[davidfestal]

I assigned it me since I'm currently investigating it in the context of the restricted environment tests (required to continue the tests until the end), and @ivinokur (who knows this codebase) kindly proposed his help to implement a potential fix in a temporary 7.9.x-based che-teia docker image (already available). So as soon as I've tested this image and confirmed it can fix the issue, I assume we would propose a PR for the controller team to review, in order to possibly finally update the generated NPM package in the 7.9.x branch of che-theia

[vinokurig]

@davidfestal Did my fix helped? I can open a PR based on that fix. Would it be useful?

[davidfestal]

I tested the docker image provided by @vinokurig based on this proposed fix: axios/axios#925 (comment) But it doesn't seem to fix the problem.

[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.

[davidfestal]

The possible fix mentioned in previous comment has been implemented and tested with the help of @ivinokur and it seems to correctly fix the bug on a disconnected environment cluster with a proxy.
I was able to start a workspace and use a terminal as shown in the screen capture.

Only remaining problem is the loading of the project zip through the proxy by wget . That a completely different problem though.

[davidfestal]

Main bug will be fixed by PR eclipse-che/che-workspace-client#28 as soon as the built MPN package is updated in che-theia.

[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