[tor-dev] Should Whonix recommend against using multiple workstations behind the same Tor-Gateway in all situations?

[Patrick Schleizer <patrick-mailinglists@xxxxxxxxxx>]

TLDR:

Should Whonix recommend against using multiple workstations behind the
same Tor-Gateway in all situations?

Long:

We at Whonix are currently wondering if we should recommend against
using multiple workstations behind the same Tor-Gateway. It's not
something we are looking forward to do since it severely decrease
usability and may not actually increase anonymity. That's why we're asking.

(Usability would decrease because: multiple-gw multiple-ws mapped 1:1 is
more difficult to explain and set up than single-gw multiple-ws; more
VMs to [maybe configure for bridges multiple and] upgrade multiple
times; more RAM usage; taking more disk space; setup taking more time;
and perhaps more.)

Whonix does use a control port filter. By default, only the most
essential Tor control commands are whitelisted such as authenticate,
quit, signal newnym, getinfo net/listeners/socks, getinfo
status/circuit-established and protocolinfo to make Tor Brower work
without any errors.

teor recently wrote:

> We don't even recommend running a SOCKS client and a hidden service on
the same instance.

Okay, makes sense. We'll update our documentation to reflect that advice.

Not too long ago Tor got some improvements:

* The number of Tor entry guards was reduced from 3 to 1.
* And guards are kept for longer. (Longer guard cycling period.)

If we encourage multiple Tor-Gateways, we subvert these improvements.

* a) I think guard related attacks are much more serious since they lead
to deanonymization, which speaks for single-gw multiple-ws setups.
* b) Drawback is that caching issues in single-gw multiple-ws setups can
lead to linking multiple workstations together.

I think a) is more serious than b). So for now I guess single-gw
multiple-ws is still better than multiple-gw multiple-ws mapped 1:1.

Perhaps we could equate the following two?

single-gw multiple-ws

* perhaps some discovery attacks even with a filter

multiple-gw multiple-ws mapped 1:1

* Even VM-level isolation is not proof against some attacks

What is worse...?
* a) single gateway sharing vs
* b) using multiple-gw multiple-ws mapped 1:1 and thereby subverting
number and duration of entry guards

Even in a multiple-gw multiple-ws mapped 1:1 setup, would these multiple
instances of Tor be really isolated from each other? Doesn't this
presuppose a perfectly contained VM? By perfect I mean to limit the
system resources any workstation / gateway can take. We are not there
yet to limit CPU load / network load / I/O (hdd) load / graphic
calculation load (/ RAM load?). (Because [not all] virtualizers support
that [easily]. [...]) (And one compromised workstation then could stress
system resources which would then make the anonymity of another gateway
suffer.)

So far we can see four options for implementation / user recommendation:

* single-gw multiple-ws
* multiple-gw multiple-ws mapped 1:1
** For multiple-gw multiple-ws mapped 1:1 setups it might be
theoretically an option to have them manually use the same Tor entry
guard? That also does not seem too great, since Tor guard selection then
would be manual? (Cloning a gateway not a reliable solution to keep
entry guards, since Tor will change them after some time and then they
will differ.)
* single-gw with multiple-ws while recommending against running multiple
workstations for activities of different trust levels / pseudonyms at
the same time
* Yet another option might be to run multiple Tor instances on the same
gateway. Tor's systemd service supports that. (Would use separate Tor
data dirs, thereby different Tor entry guards.)
** If you recommend we should use multiple Tor instances, should we try
to configure them to use the same Tor entry guard or bridge?

A list with all pros and cons for either option based on what we learned
recently on this list has been created:
https://www.whonix.org/wiki/Dev/Multiple_Whonix-Workstations
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev