Jump to: navigation, search

Dev/Multiple Whonix-Workstations

< Dev

Single Tor-Gateway with Multiple Workstations[edit]

Pros:

  • Not subverting Tor guard selection and cycling.
  • Single Gateway VM uses less resources.

Cons:

  • Some unforeseen way malicious VM "X" can link activities of or influence traffic of VM "Y"
  • Maybe sending NEWNYM requests in a timed pattern that changes exit IPs of VM Y's traffic, revealing they are behind the same client?
  • [XXX] perhaps some discovery attacks even with a control port filter can leak VM's guards and even entire circuits
  • Maybe eavesdropping on HSes running on VM Y's behalf?
  • caching of DNS
  • caching of HS descriptors
  • preemptive circuits.
  • circuit cannibalization (cannot be isolated)
  • SSL state
  • guard state
  • consensus availability and content
  • descriptor availability and content
  • connectivity (or lack thereof)
  • uptime
  • ControlPort config information
  • ControlPort config changes
  • And many more.
  • [1] [2]
  • "We don't even recommend running a SOCKS client and a hidden service on the same instance."
  • If the host or Whonix-Gateway internet connection goes down, all workstations will go offline at the same time which could aid to link them to the same pseudonym.

Stream Isolation defends at the remote end. Not at the client end.

Multiple Tor-Gateways mapped 1:1 to Workstation VMs[edit]

Pros:

  • Conceptually simple. Uses a different Tor instance so no need to worry about all these questions.

Cons:

  • Subverting Tor guard selection. (For better anonymity, Tor developers decided to reduce entry guards from 3 to 1.)
  • Subverting Tor guard cycling. (For better anonymity, Tor developers decided to cycle Tor guards less often.)
  • Uses a different entry guard which can increase chance of running into a malicious relay that can deanonymize some of the traffic.
  • Uses extra resources (though not much as a Tor Gateway can run with as little as 192MB RAM).
  • Links traffic at different guards to the same source IP address
  • [XXX] Even VM-level isolation is not proof against some attacks
  • Much worse usability.
    • More difficult to explain to and grasp by users.
    • More hassle setting up bridges.
  • Non-Qubes-Whonix:
    • Wastes lots of disk space.
    • Lots of more VMs to keep updated.
  • If the host internet connection goes down, all workstations will go offline at the same time which could aid to link them to the same pseudonym.

Multiple Tor instances on same Gateway[edit]

Idea:

  • Running multiple Tor instances on the same Gateway. [Tor's systemd service supports that. (Would use separate Tor data dirs, thereby Tor entry guards.)]
  • Ideas:
    • *Might* be simpler to make all instances of Tor use the same Tor entry guards.
    • There could be a Tor "master" instance. It would fetch consensus and set entry guard. All other Tor slave instances would use that, perhaps using symlinks or so. Might require features that Tor does not provide yet.

Pros:

  • Just one gateway.

Cons:

  • ...more from above
  • If the host or Whonix-Gateway internet connection goes down, all workstations will go offline at the same time which could aid to link them to the same pseudonym.

Tor Hidden Services[edit]

Compartmentalization[edit]

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

Safe to recommend:

  • use one gateway / workstation[s] combination for simple client activities (browsing, mail, chat)
  • use another gateway / workstation[s] combination where add_onion is whitelisted, i.e. where using Tor ephemeral hidden services is white listed

Deanonymization is more at risk when using Tor hidden services compared to just using Tor as client. This is because Tor hidden services can be made to talk by connecting to them. A whole different class of attacks.

So when one just users Tor as a client and that workstation gets compromised, it would be a safer if that VM did not have access to Tor creating ephemeral hidden services, since that allows more deanonymization attacks.

Ephemeral Detached Tor Hidden Services[edit]

When using detached ephemeral onion services, VMs can read onion service keys and hostnames of other VM as well as shut them down.

  • Requires Whonix 14 or above (Whonix 13 control port filter does not support ephemeral onion services).
  • Only when white listening the command for listing ephemeral onion services in control port filter.
    • It's not clear that will be required since there are no ephemeral HS applications in the wild that would require that command.

Draft[edit]

Patrick[edit]

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

HulaHoop (slightly modified by Patrick)[edit]

Thanks to teor's input we updated our wiki info.

Given all the disadvantages of multi-workstations sharing a single gateway, is it still worse than having multiple Tor entry guards if we use of separate gateways? Which is a lesser evil?

Discussion on other setups:

  • For multi-gw 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.)
    • should we try to configure them to use the same Tor entry guard [or bridge respectively]?
  • As a workaround, what do you think about running single-gw with multi-ws while recommending against running multiple VMs 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 Tor entry guards.) Each connected to a workstation via its own private virt network. The advantage of this is conservation of machine resources.

What are your views on this?

See Also[edit]

Footnotes[edit]

  1. https://lists.torproject.org/pipermail/tor-dev/2016-October/011591.html
  2. https://lists.torproject.org/pipermail/tor-dev/2016-November/011634.html

Random News:

Please Contribute by answering questions.


Impressum | Datenschutz | Haftungsausschluss

https | (forcing) onion
Share: Twitter | Facebook | Google+
This is a wiki. Want to improve this page? Help welcome, volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation. Whonix (g+) is a licensee of the Open Invention Network. Unless otherwise noted above, content of this page is copyrighted and licensed under the same Free (as in speech) license as Whonix itself.