A) Ephemeral
That is one big disadvantage loosing whonix protection of host separation. Also not trivial not only because it would circumvent whonix protection, but because tor’s controller doe not show the port service is running on. Example: setup an ephemeral onion service (tor-ctrl-onion -A -l 80) and try to get any information about it, if I send GETINFO onions/detached or tor-ctrl-onion -L, it only show the hostnames. This means that the webserver script cannot consult the controller to find the port it is running on, the hs pk would need to be saved along side its port for this to work, and a format to be defined. Related:
- maybe a
--permanentflag to be used so tor-ctrl-onion saves the PK and the ports and flags to a file, but every time tor receives and INT signal, the user would need to re add those files to the controller, possibly by a systemd script that send these commands after tor is (re)started. - this is the easy but less secure option, but does this usability justify the compromise? I mean, almost non whonix user is already running with their PKs on the same host unless they have enough knowledge to configure a remote host controller, and making whonix onion services vulnerable to attacks that already happen on other systems is not a gain on my view, even though the
permanentoption can still be done because it might be useful anyway.
B) config files
- qubes-whonix → qrexec as mentioned above
- non-qubes-whonix →
--weboption would need to circumnvent if check if service exists and the ports would need to be provided via command line, and yes, would be one command on the gateway and one on the workstation. GWonionjuggler-cli --activate -s web -p 80, WSonionjuggler-cli --web -s web -n -p 80 -w /var/www/folder --no-check-service. There is no such option yet, would need to be checked if this is viable.
Anyway, the web option is not magic, it is a sample nginx virtualhost configuration file for static webpages, advanced uses will always need to be done manually.