Replies: 3 comments 4 replies
-
|
this may be an option for the developers to consider integrating into CasaOS: Or maybe leverage Caddy with its "Local HTTPS" feature (leverages smalltep already) as a ssl reverse proxy component of the CasaOS architecture: |
Beta Was this translation helpful? Give feedback.
-
|
The better option is to used one of the free domain services or CasaOS to offer people a free domain services off with DynDNS with a domain they purchase like casasos-home.org so users would be user1.casaos-home.org just like Asus and other router companies offer. Then use the free certs from Let's Encrypt. |
Beta Was this translation helpful? Give feedback.
-
|
I think it depends on the use case: Internet accessible (public facing) or Internal only (private network) In your recommendation, while valid and has merit, the user would need to have ports open on their firewalls for the end to end process to work unless the implementation is similar to how Cloudfare Zero Trust works https://www.cloudflare.com/products/zero-trust/ or how Home Assistant's Nabocasa works https://www.nabucasa.com/faq/ (https://github.com/NabuCasa/snitun), both where user does not need to setup any ports on their firewalls and the cloud intermediary (in your example "casasos-home.org") would provide the security and functionality required to enable "user1.casaos-home.org" for the "subscriber" while maintaining private end to end encryption for the users's communication with their internal casaos instance(s) and use letsencrypt cert management on per user instance basis. https://letsencrypt.org/docs/allow-port-80/ For the internal private network use case, it would be ideal some simple private cert management solution for enabling ssl to address apps that have ssl dependency to function where the user has no desire to have access from public internet or desire to open ports for letsencrypt, or have a public dns entry. In this use case, the user may want to have private dns internal to their network of even have an app that calls another app and uses ssl for inter app communications. Of course, this is also beyond the skill of a typical end-user, but still could be a use case for the paranoid :-). As an infosec colleague once said, security is all about trust and where on the paranoia dial you are currently turned to. Ideally, in a perfect world, the solution would be simple enough for an end-user but flexibly enough to allow transition/choice between the above use cases while descriptive enough for the end user to understand the functionality and limitations of chosen option where appropriate. |
Beta Was this translation helpful? Give feedback.
-
|
I completely agree that the best option is to have ZERO access from the internet to any internal servers by port forwarding at the router or punching a hole in the firewall. My recommended method instead for external access by home users to their internal home networks is instead a ZERO trust VPN which does NOT require punching any holes in the firewall thus to the wild internet public there is no access because the firewall blocks all traffic attempting to get to the internal network. This also means there is ZERO complexity of setting up a reverse proxy either. If it works on the local LAN for the user then it will work via the VPN no problem. I highly recommend instead using ZERO trust VPNs like these which have clients for every device out there: Tailscale - which is built on top of WireGuard and is open-source. ZeroTier - which is also open-source One of the advantages of Android is you can have it auto launch a VPN on per app usage. So when you open specific apps it automatically launches the VPN to allow connection for that app. Which means once the user goes through the one time setup then it just works like magic for them. Nothing to think about. Not sure but even that might be able to be automated during the install. |
Beta Was this translation helpful? Give feedback.
-
|
But you are correct there needs to be some solution for Vaultwarden and 2FA, even though they may not be accessible from the Internet they still will NOT let you login unless they are running on HTTPS. Which is a problem for the whole, just pick programs/services you want and it just works. Currently they do NOT "just work" out of the box. Which creates more support issues for explaining to users why it doesn't work and how to fix it. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, this is my exact scenario. I'm using wireguard, and I don't want to open my ports. But not being able to use out of the box some services, is indeed killing the experience as a whole. |
Beta Was this translation helpful? Give feedback.
-
|
this may be useful in the search for developing a CasaOS solution for apps that require HTTPS to function.: |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem? Please describe.
Lot of services require a secure HTTPS connection (for example Vaultwarden), but it's quite messy to set up, especially if one would like only to use the server on LAN (maybe accessing through WireGuard or any VPN), and doesn't have a domain name, or a CA certificate issuer.
Describe the solution you'd like
A built in, globally working, self-signed option, something similar to the one in Embassy OS.
Describe alternatives you've considered
Currently, I've tried to set up this functionality with OpenSSL and Nginx reverse proxy for Vaultwarden, but it can really mess up CasaOS itself if I don't have any domains and subdomains.
Additional context
Beta Was this translation helpful? Give feedback.
All reactions