[feat]: allow connections over plain http

[AndySchroder]

Prerequisites

• [X] I have searched for existing issues that already suggest this feature.

Describe the Feature Request

Embassy allows for some limited activity using http over the local network. However, when trying to use a service, we get a "You are using an unencrypted http connection". I realize this is trying to force people to be more secure, but the steps required to setup a CA are a bit more involved than I want to mess with just to test and evaluate Embassy and see if I want to use it at all. Also, every time I re-image an SD card, aren't I going to need to re-load a new CA everywhere?

Describe the Use Case

Testing and evaluation of start9/embassy

Describe Preferred Solution

Allow http after a warning message is confirmed.

OR

Allow a simpler, less intrusive setup like a wireguard VPN as is mentioned here: https://github.com/Start9Labs/embassy-os/issues/1607#issuecomment-1450733202 . The wireguard VPN can easily be setup and torn down on the client using Network Manager.

Describe Alternatives

Use kiosk mode, but this is limited because I can't copy/paste anything into that.

Anything else?

No response

[dr-bonez]

Is there a reason you can't just add a security exception for the site in your browser? An encrypted connection without a trusted cert is still better than a plaintext connection. ARP spoofing attacks are more common than we are comfortable ignoring.

[AndySchroder]

That option seems to have been removed in recent versions of Firefox.

[MattDHill]

I am running the latest version of Firefox and this is not the case. I would be surprised if they ever did something like that, even Chrom allows it. Simply visit your unique .local URL using https, and Firefox should present you with a big ugly insecure warning that you can simply bypass.

[AndySchroder]

I'm getting the following:

After further investigation, it seems this specific error comes when you try to go to the embassy by its IP address rather than a hostname. There are a few reasons why I want to do that (1) to choose whether I'm accessing the embassy by wifi or ethernet and (2) because I run a local fully resolving nameserver on my workstations so whatever magic you use to establish the .local hostnames is not possible. I'm not sure if my setup leads to a further incompatibility because you seem to be running a proxy web server that takes connections to different alias host names and redirects it to different webservers inside of docker containers?

When I use a workstation that does not run a fully resolving local nameserver and try connecting with a .local hostname, I get the same message as you show above.

[kn0wmad]

I'm getting the following:

After further investigation, it seems this specific error comes when you try to go to the embassy by its IP address rather than a hostname. There are a few reasons why I want to do that (1) to choose whether I'm accessing the embassy by wifi or ethernet and (2) because I run a local fully resolving nameserver on my workstations so whatever magic you use to establish the .local hostnames is not possible. I'm not sure if my setup leads to a further incompatibility because you seem to be running a proxy web server that takes connections to different alias host names and redirects it to different webservers inside of docker containers?

When I use a workstation that does not run a fully resolving local nameserver and try connecting with a .local hostname, I get the same message as you show above.

mDNS (and aliasing) is what we're using - obviously we cannot support all the possible network configurations, but most routers support this. You will have more options in this regard soon though, as our story around connectivity is evolving, beginning with our upcoming OS update (no ETA at this time).

[MattDHill]

We now sign certs for plain IP too, so you don't need mCNS to use SSL :)