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.

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 help in testing new features and bug fixes in Whonix.


Impressum | Datenschutz | Haftungsausschluss

https | (forcing) onion
Share: Twitter | Facebook | Google+
This is a wiki. Want to improve this page? Help is welcome and 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, the content of this page is copyrighted and licensed under the same Free (as in speech) license as Whonix itself.