[FEAT] Support for restrictive networks

[hatl]

Is this a new feature request?

• I have searched the existing issues

Wanted change

Make SealSkin work via a single port: 443
Alternative: allow using 2 different (sub-) domains for API and session connections.

Reason for change

I am looking for a way to use SealSkin in environments with restrictive network policies (e.g., public Wi-Fi, hotels, or corporate guest networks).

The Challenge: Many of these networks implement strict filtering, blocking standard VPN ports and protocols. In many cases, port 443 (HTTPS) is the only open port allowed for outbound traffic.

Proposed code change

No response

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[thelamer]

The dual port design is implemented for a couple reasons but the core is that in chromium I cannot talk to an external server unless it has a legit cert so I use http and do my own more intense E2EE for the data in transit. There is other stuff but that is the core reason and the reason it has not been ported to firefox yet.

Now for a single port solution to work this needs to be not tied to the extension basically and be a standalone web server app which is coming for more platform support, but for right now I need to focus on the rendering stack and finish off wayland it might be a month or more before anything like that exists.

[hatl]

Thanks for the feedback.
Since Caddy is anyway already part of the package: why not use it to get a legit certificate via Let's Encrypt?
This way you would not need to implement your own E2EE.

[thelamer]

I just had to spend three months showing people how to put https in a url bar. I do not think you understand the base skill level of the majority of our users.
But basically it is a death sentance for an app if you need a domain/cert, hard lockout of 99% of people just trying stuff out on their new Linux server.

[hatl]

I don't understand. Extracting the keys from Docker logs seems to me way harder on the user side than using https - especially when you can give them a pre-configured Caddy instance.
Besids: any modern browser checks if https is offered on the remote side and automatically prefers it when available.
Maybe a Caddy could be part of the default setup - that way the users won't have to take care about https support.

[thelamer]

Please explain this process, it would expand into the complexity of setting up a reverse proxy as far as I can see.
What providers would you support, what plugins would you install, how would you convert out env vars into configs?

We maintain a reverse proxy with SWAG it is not just about "making a certificate"

Also as I said there will be a stand alone mode in the future, just in general this whole key setup process which now is literally just using a file in your config directory to configure the extension is because people are bad at setting up auth, and if I am going to tell people to expose something to the internet it needs to not have a way where they can disable security because we are the ones that get flooded with the "my server got owned" and "linuxserver containers have a crypto miner" and "linuxserver backdoored my server".

[hatl]

I would just use a very simple Caddyfile.
No need to use a SWAG container - since you already install Caddy in your image.

Regarding authentication: none of the linuxserver webtop containers have any kind of authentication.
The SWAG image also doesn't enable auth by default.
So one option would be to follow that scheme and let the user decide.

Alternative: A very simple and widely used way would be "Bearer" auth - which can also easily be achieved with Caddy.
This covers https via Let's Encrypt, covers authentication and could be used to get rid of the "2 port" approach.

{$DOMAIN} {
  @goodToken {
      header Authorization "Bearer {$TOKEN}"
  }
  handle @goodToken {
    handle /app/* {
      reverse_proxy {$APP_DESTINATION}:{$PORT}
    }
    handle /api/* {
      reverse_proxy {$API_DESTINATION}:{$PORT}
    }
  }
}

[thelamer]

That is exactly how auth is handled on the session port already jwt and bearer, but you get your fresh generated tokens from the e2ee endpoint.

I get you want a single port architecture, I am telling you it is coming. My point is there is no silver bullet for the legit cert that would be required to make it work.
My other point is I do not trust people to setup auth, this is a port exposed to the internet with basically root ssh access to your server as it is piped into the docker socket. The only auth I am comfortable with there is RSA 2048 and up public private key cryptography. So even in the single port configuration you will still have the key concept where auth is not stored on the server just public keys.

I get what people want, they want a fully connected external auth ecosystem like they already have with openid oauth and 2 factor. The problem is those have not only a learning curve but can easily be misconfigured to let anyone into your server.
You expose a plex container no big deal they can run some network scans and maybe a crypto miner, but if they have the docker socket they own the whole server and all your data.