Separate dedicated TorHS for Receiver’s, Administrator and Whistleblower access

[fpietrosanti]

Separate dedicated TorHS for Receiver’s access, Administrator access, Whistleblower submissions.

This ticket security improvement would lead to have 3 different access URL for 3 different users.

Split the TorHS over which is possible to apply for Submission, the ones used by Receivers to access and the Administrator interface. This provide important access-restriction with a vpn-like security model, segregating communication channels.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[fpietrosanti]

The access to the administrator and receiver interface must be also protected by an additional simple password, to demonstrate the knowledge to have the right to access that kind of interface.

[vecna]

there are various degree of deepness in this issue, but the most important thing is: Tor need to be configurable/manageable by globaleaks or this kind of integration need to be enabled by /etc/defaults/globaleaks ?

[fpietrosanti]

@vecna eh yes, I think that this one is a major feature that's going to introduce a lot of complexity for the user (admin/receiver) that need to know their own TorHS somehow. Probably having automatic configuration, with #70 fully implemented would be useful. Additionally it should be specified how to manage, log and report access restriction (what if admin try to use receiver interface or receiver try to use whistleblower interface).

[fpietrosanti]

Regarding on "how to set them up" i think that we need to wait until we verify if we can manage the Tor process or not on our own code, to simplify installation process and TorHS key management.

[evilaliv3]

This ticket could be re-evaluated in relation to the new possibilities added by the integration of txtorcon and of the ephemeral hidden services.

[NSkelsey]

Further we can add a layer of authentication via Tor implemented SRP to the service so that Admin's and receivers are further protected via a shared password. With a real split of functionality and handlers across two or three onion services, we could accomplish several goals by implementing this:

1) minimize the size and load time of the whistleblower interface (by modularizing the interface) 2) Protect the receiver and admin roles with an additional layer of auth 3) Move simple DOS protection for admin and receiver routes into tor's SRP auth

I think we can move this into OTF 1.4 (2017-18) modularizing the client. I feel that taking on this piece of work could even lead us to the correct splitting of functionality to produce a dedicated desktop client.

OTF 1.4 for reference:

• Organize modularization of the application by dividing the framework dependant code from the data structures and alghoritms proper of the GlobaLeaks implementation
• Develop framework dependent tests (e.g. Angular Controller tests)
• Organize tests for the GlobaLeaks Javascript libraries (e.g.Tests of the PGP key generation with the parameters used by GlobaLeaks)