Web-UI security: HTTPS, sessions, and logout button

saspus · 30 January 2019 08:55

Currently duplicacy-web allows anyone to connect to the web interface with the admin credentials, including another user on the same machine if listening on loopback, or literaly anyone else if listening on other interfaces, after admin logged in into the instance. And because duplicacy has read access to everything by design that is a pretty glaring security hole.

In addition, there is no way to logout from the interface so once logged in it forever exposes everything to anyone passing by who cares to look.

Implementing logout button would be a bare minimum to reduce amount of time it is completely unprotected.
Session key would also make sense
1 and 2 is pointless without HTTPS (passwords can be sniffed and session key stolen)
So, we need HTTPS, albeit with self-signed certificate.

Is any of this planned?

In the meantime, possible workaround could be to lock it down in a container and access UI via SSH port forwarding, but that is a lot of hassle and I did not think it through completely to be sure that no other issues come up.

themmm · 30 January 2019 14:19

I thought the same and “resolved” the problem by setting up a ssh tunnel on my client machine:

ssh -l 8888:127.0.0.1:3875 “your-server-address” then point your browser to http://127.0.0.1:8888

I think if anyone is able to access the computer running duplicacy with priviliges like listening to the loopback interface there is not much you can do anyway.

You could also setup a reverse proxy like nginx that is secured with a ssl certificate.

Anyway a logout button would give me a better feeling too

saspus · 31 January 2019 05:46

Yes, I use the same workaround, but my question was
more about the roadmap in principle than anything: if that is planned I’ll just wait; otherwise I will just have to bake sshd into the docker container and live with having to start the tunnel before configuring duplicacy, which is not the end of the world really, just not nice…

I think it is a very standard usecase: e.g. about multi-user desktop OSes. Or network storage servers (Synology DiskStation in my usecase). Quite a bunch of legit users can login and do stuff, including talking to loopback; having access to duplicacy UI gives them access to each others data via restore workflow, so all ACLs go out of the window.

I agree that containerizing it and accessing via SSH is a reasonable workaround for now.

themmm · 31 January 2019 11:20

I get your point and agree that it would be way more convenient!

gchen · 1 February 2019 13:39

I’ll add the HTTPS support and add a Log Out button somewhere. This should be done before the official release of the web GUI.

Derek_v2 · 2 May 2020 01:16

Is the webGUI official yet (or still beta)? I’ve installed 1.3 and there’s no logout or https that i can see

saspus · 2 May 2020 01:43

yes, https is working with LE certificates, custom certificates are not yet supported. AFAIK session is still open to anyone once admin authenticates, afaik.

Personally, I found that instead of needing to maintain yet another certificate for a service I will use once a year tops I’d rather use HTTP over SSH port tunneling (and plan to continue doing so even after the above issues are addressed): I have a function in my .zprofile called “open_duplicacy” that establishes the ssh port forward and connects to the UI in the browser:

open_duplicacy_remote() {
	ssh -N -L 3876:127.0.0.1:3875 me@my_server_where_duplicacy_is_listening_on_loopback_only &
	sleep 1
	open http://localhost:3876
}

THis is not less secure than HTTPS, handles both authentication and encryption and once that is done HTTP works just fine.