TLS by default

[l0rd]

Is your enhancement related to a problem?

I don't see any scenario where users would want to use unsecured http communications.

Describe the solution you'd like

TLS should be activated by default. It should not be something that the user should bother with.

• [POC] TLS by default [POC] TLS by default #15313
• Implement TLS by default for helm Che installer feat: Implement TLS by default for Minikube + Helm installer che-incubator/chectl#476
• Implement TLS by default for operator Che installer Implement TLS by default for operator Che installer #16052
• Dashboard messages should be more accurate when self-signed cert issue happens Dashboard messages should be more accurate when self-signed cert issue happens #15298
• Redesign SelfSigned cert error page Redesign SelfSigned cert error page #16065
• Dashboard must clearly describe solution when self-signed TLS issues Dashboard must clearly describe solution when self-signed TLS issues #16245
• [chectl] Replace "-s/--tls" parameter with "--no-tls" due to installing Eclipse Che with TLS by default [chectl] Make it possible to install Eclipse Che with "--no-tls" option #16302

[sleshchenko]

I'm afraid we are not able to provide every user normal certificate.
And if we go with a self-signed certificate (in the same way as minikube/minishift) it might bother user since:

1. they need to import CA certificate into the browser
2. add every Che endpoint to exclusion, like after workspace start, open each of workspace endpoint and mark them as trusted, otherwise, Iframes won't be loaded properly even without a clear message.

I don't say that it's not possible, just sharing thoughts that might be not detailed enough.
So, this issue is not only about changing values of the default value of the parameter and about the investigation of how we can handle it and what is UX.

[davidfestal]

I'm also a bit worried about the fact that, in the current state of the Che operator, successfully enabling TLS required correctly setting the related selfsignedcerts field. And this can be a risky thing, since it has to be consistent with the status of the Openshift router certificate, else it will fail with non-obvious errors.

So providing a TLS-enabled default that will work in all cases is tricky today.

[l0rd]

@sleshchenko yes we should support self signed certs of course. That may be tricky but we have already lost a lot of time because we are not testing with TLS enabled locally. We should automate as much as we can and guide user to accept the self signed certs.

@davidfestal it should not be "risky" otherwise users that enable TLS will always "risk" to have problems. We want to make TLS the default because we want to put those kind of problems in evidence so that we will fix them.

[mmorhun]

This issue is required for new webview plugin API implementation to work. Without it webviews are broken.

[sleshchenko]

It seems to be completed. @tolusha Could you revise it?

[tolusha]

@sleshchenko
We are going to add a couple of preflight checks

[tolusha]

The following issues will be done out of the TLS epic:
#16762
#16764
#15301