whonix, torrents, and being a good tor citizen

Development
3

Moved this to development sub forum. If this was a user support question, I would just say ‘unsupported’. ( Frequently Asked Questions - Whonix ™ FAQ )

This requires quite some thought and whonix-gw-firewall modifications. I am personally a bit more interested to have a VPNBOX (using a VPN as full replacement for Tor) rather than selective circumvention maintained by someone else, but nevermind.

I suggest step by step:

  1. Not start with Whonix. Getting a VPN-only-Gateway working first.
  2. Making that a “selective VPN gateway”.
  3. Getting Whonix-Workstation to work with the VPN-Gateway.
  4. Modifying Whonix-Gateway.

Or another approach, take a plain Debian [jessie] - and then review, and add one essential Whonix network related package one by one until you have the most basic functionality without sdwdate and stuff. Perhaps that would help to demystify Whonix generally.

(Btw the Whonix VPN tunnel combination instructions have recently been improved. - Instructions on how to disable uwt and socks proxy settings may be useful.)

(Btw to understand Whonix internals better generally, this page might help. Just skim through it.

Somehow I more and more dislike such pages. Makes it all look more, and more complex and daunting than it actually is.)

4

Thanks for the link. Not using qubes - but, having come across whonix, and thus qubes, I am certainly intrigued. Should I ever purchase another sufficiently powerful laptop, it is in my mind to go for it, then. e.g. I see web references to dual boot installations, so if there’s something ‘lacking’ in the xen / qubes performance / capacity (e.g. 3D?), I’d be able to boot native kubuntu.

Host OS is Kubuntu 12.04 LTS.

5

Re: your post, generally - fair enough, 10-4, good stuff, thank you.

[quote=“Patrick, post:3, topic:1766”]I am personally a bit more interested to have a VPNBOX (using a VPN as full replacement for Tor) rather than selective circumvention maintained by someone else, but nevermind.
[/quote]

Seems reasonable, but then this is also chicken and egg.

By investigating starting from a ‘secure’ environment (whonix), all the ‘good thinking’ that went into it can be leveraged. e.g. To only disable surgically. And, to put it another way … ‘this’ (say a proxy or iptables rule setting) is present … there must be good reason - Consider carefully issues surrounding, and so on.

I take your point about starting from Debian, however then it becomes an issue of what fiddly bits need to also be added to make it ‘secure’. Since you don’t know what you don’t know, there will always be things missed and elements forgotten - perhaps exposing one to the very things whonix protects one against.

I think this is both chicken and egg and iterative. There is top down, and bottom up, and each approach makes sense in their own ways at their own times.

i.e. If a VPNBOX article started with ‘all the elements that make whonix’ one could ‘work up’ (follow) the common steps (leveraging the whonix work) to the diverging point, and work down from the endpoint back to the point of divergence (and rebuild up what’s still germane.)

Which is to say, starting from Debian, you can’t prove the negative. Working down from whonix, the negative is distinct (by the absence). Thus I say chicken and egg, and iterative. I don’t expect a first iteration will be 100% successful - so work down in the first go, work up in the second.

In the mean time … my memory of torrent ips, ports, protocols is rusty. If someone knows where such is concisely laid out, please note the link.

6

Do you care about anon yous development? I.e would a leak, someone finding out, that personally you’re developing this matter to you?

7

(Potentially) ‘Dangerous’ question [/ to answer (?)]. (Perhaps. Can’t prove a negative.)

Why do you ask?

8

I don’t believe anymore, that a comprehensive design documentation would make things simpler. Learning isn’t writing big books and having someone read and magically remember it all. It’s a discourse. Unfortunately, the discourse way seems the only one.

[ Otherwise, someone like me should be able to understand Tails by reading their design documentation, right? Even though the Tails one is much more comprehensive, and they have a policy to update it on changes, it misses so many pieces, that I sometimes cannot make head or tail of Tails myself. - For example, I spend at least an hour trying to figure out why vimeo works in Tails but not in TBB and not in Whonix - Diff between Tor browser inside whonix and tails and windows - #10 by Patrick - to no avail. ]

Understanding Whonix. Task nr. 1.

Go to: Whonix · GitHub. Have a look at each package and their short description one by one. Example…

  • whonixcheck - Anonymity and security check - systemcheck - Security Check Application — Essential for now? No. Perhaps later.
  • rads - Same.
  • anon-shared-helper-scripts - probably not for now. (You will notice if you miss this package as part of a dependency.)
  • anon-gw-anonymizer-config - Tor Configuration and Tweaks for Anonymity Distributions — Definitively need this.

Just skim through it.

(Since the package list on the web can change… Once you have whole Whonix code… Get a list of all Whonix packages.
cd packages
ls
Base your notes upon those.)

If some package is unclear, click on it. Read a bit more. Read the long package description perhaps in debian/control.

9

Because my answer to your previous post before my further inquiry depends on this. Nevermind. I assume “yes, matters for you” for now. Will answer soon.

10

Seems reasonable, but then this is also chicken and egg.

If you want to develop this while staying anonymous makes this a lot harder. That’s a chicken and egg issue indeed. I would still start with plain Debian then to learn all this stuff. But making sure that even then all your traffic stays torified someone. Perhaps nested virtualization if performance is good enough. Or physically isolated Tor-Gateway. There is no perfect way to do this.

By investigating starting from a ‘secure’ environment (whonix), all the ‘good thinking’ that went into it can be leveraged. e.g. To only disable surgically. And, to put it another way … ‘this’ (say a proxy or iptables rule setting) is present … there must be good reason - Consider carefully issues surrounding, and so on.

I am not saying you should start your own project. Just suggested a way to understand Whonix better.

11

Yep, but this essentially goes back to your comment in another thread.

‘Rationalizing’ design documentation down / linked to code implementation, and back up, such that any given documentation element is only present once. (One of the problems of which is different presenters at different levels - e.g. forums <-> wiki <-> git <-> text of actual code in an actual cleartext file.)

Let alone the common premise that comments in code are useless / outdated as soon as they’re entered. Code changes later can make them incorrect, and accompanying comment modification in practice doesn’t get done 1:1 as often as we would like. (Good commenting thus also seems to become an art form.)

Regardless / in the end … having such documentation serves as a good point reference every time you come back to an aspect. You have to at least once carefully chew through each element to grok a beastie and get it under your belt, but having done so, coming back later to remind you of the details of the fiddly bits is a huge time saver.

12

Absolutely. I get that / didn’t take it that way.

In essence, your VPNBOX, or rather, your VPNBOX wiki article, is a fork. Then tweaked for the ‘different’ purpose.

Not entirely certain of that. In the end / cross-person answer is all but prefixing the VPNBOX wiki article with ‘follow the design principles and steps of building whonix per ‘these’ documentation links’, diverge from those steps in ‘these’ ways … laid out below … based on steps from ‘here’ as extracted on mm/dd/yy.

i.e. At that point, documentation is - anonymity probably doesn’t matter. Non-nefarious documentation is what it is. In a perfect world anonymously (or not) contributing such documentation shouldn’t be impactful. Sadly, we don’t live in a perfect world. (Mind you, level of impact likely depends upon where on the globe you live - and http://www.whonix.org being a single point of documentation entry I guess you have to assume worst case at all times, up front.)

13

Notes for thread:

ktorrent - has ability to set DSCP.
ktorrent - has no ability to NOT set proxy / set no proxy, er, NOT use machine set proxy. Apparently a KIO limitation is either you set the proxy or use the system’s - you cannot set no proxy.

qbittorrent (also in repository) - has ability to set no proxy.
qbittorrent - has no ability to set DSCP

i.e. Desire: take advantage of the protections for which whonix exists in the first place. Whether you use the browser proxy, the system proxy, or no (workstation) proxy (because by default gateway proxies everything coming in) … they’re just different pathways / flows into/through that protected system. A good thing.

However, the quest is for a surgical criteria by which to except particular traffic to go out beside Tor, not through it. (To be the good citizen as the thread’s title notes.) Still feels like the appropriate way to do that is via proxy settings within an app. Thus a particular app’s traffic can be identified - and particular rules applied as appropriate. [Assumption: VPN present, with whonix’s vpn kill switch enabled.]

qbittorrent ‘natively’ (with no proxy set) torrents in whonix-workstation - albeit, sadly, still through Tor. Working on that.

This is mind boggling complex. So many players, so many fiddly bits. (Glad this got moved to dev!)

14

Notes for thread:

Initially, I expected a vpn on -gateway, app well identified / constrained for net usage, and corresponding -gateway iptables changes to let just that app get through un-tor’red. -gateway would have whonix_firewall vpn kill switch turned on.

It occurs to me there are two other approach vectors:

(1) vpn on -gateway, add additional virtual net adapters to each vm (named ‘clearnet’?), then iptables rules could constrain via interface. whonix_firewall vpn kill switch turned on.

(2) vpn on -workstation, app set to use tun0 only, iptables on -gateway set so vpn traffic (only) goes through un-tor’red. vpn kill switch (app) installed there on -workstation.

Anyone with any thoughts / preferences / pros / cons to any of these approaches (or suggest others)?

Seems to me such would get the VPNBOX mentioned, or at least be a hybrid VPNBOX. Perhaps there is some value in that. (?)

15

rAntOCauDgb:

(named ‘clearnet’?)

User ‘clearnet’ on the gateway is already taken and defined.

Named ‘vpn’ perhaps.

(1) vpn on -gateway, add additional virtual net adapters to each vm
(named ‘clearnet’?), then iptables rules could constrain via interface.
whonix_firewall vpn kill switch turned on.

Hm. Right. Whonix-Gateway default interfaces kept as is and providing an
alternative VPN-only route. Implemented by an additional virtual
internal-only gateway network interface.

(2) vpn on -workstation, app set to use tun0 only, iptables on
-gateway set so vpn traffic (only) goes through un-tor’red. vpn kill
switch (app) installed there on -workstation.

I am not following.

Perhaps there is some value in that.

Yes, because from there, with (1), a VPN-only gateway for everything
would just be a matter of the default route configuration.

16

Yep. This was a virtual network name, not a userid. i.e. Equivalent to the ‘whonix’ virtual network name.

Firing up of a vpn on whonix-workstation would create a tun0 device. App can be set to only use the designated interface - here, tun0. Routes (likely) would be prevented from being added by openvpn [i.e. tweak of .conf file] - thus nothing else on the machine (vm) is aware of the additional adapter (tun0), so all current routing continues as usual. [Assuming app set to tun0 needs no routing, else specifics adjusted accordingly. e.g “route add any vpn if tun0” equivalent.] iptables modified on -gateway to clearnet pass traffic from that workstation (tun0) interface. (Details as to how gateway knows that to be worked out.)

So:
(0) Identify app specific traffic, vpn with killswitch on -gateway, and its iptables adjusted to clearnet only that app’s traffic.
(1) vpn with killswitch on -gateway, additional virtual lan to both, rest as in (0). Difference is traffic is identified by virtual lan it’s traveling over, rather than having to try to divine what is ‘app specific traffic’.
(2) vpn on -workstation with killswitch via tun0, rest as in (0). Difference is traffic is identified by (workstation) interface it’s traveling over (tun0), rather than having to try to divine what is ‘app specific traffic’.

In essence (0) is creating a template/process for strapping on well defined app traveling clearnet onto whonix. Seems worth doing (documenting). [But can’t think of any other such candidates than torrent, that isn’t already or wouldn’t be baked into whonix via uwt - should popular use case be presented.]

Not sure I’m following you there. Default routes / current routing should apply in each case - or I’m missing something. Similarly, iptables mods are necessary in each case - if only to pass the traffic through. As stands, whonix_firewall would tor or block all udp or vpn traffic. So iptables tweaks are necessary in each scenario. (Granted tweaks simpler in some cases.)

Problematic is still corralling (identifying) the app traffic (including udp) to know necessary iptables changes. However, current best guesses are tracker connections via current (tor’ed) http, which should be no great burden to tor - perhaps via http proxy setting of localhost:9122 (9150?). Any udp traffic happens via socks5 proxy - the ip of which gives us the ip for use in iptables rules. Other traffic unknown, and therein may be the rub.

It is not clear to me that any of the approaches holds any specific advantage over the others. Thoughts welcome.

17

How can you configure an app to use a specific interface? Is this like configuring proxy settings? Very few applications support this, right?

18

I was just thinking ahead.

Yes, because from there, with (1)… That means, once (1) is implemented… A VPN-only gateway for everything as opposed to selective would not be far away in development.

Nevermind that. It’s not important for implementing this proposal.

19

Yes. Set same place as proxy settings.

apt-get install ktorrent - settings / configure ktorrent / network / network interface - all | lo | eth0

apt-get install qbittorrent - tools / options / advanced / network interface (requires restart) - any interface | eth0

Can’t say I see such all that often. Also can’t remember to be able to say where all I do see it. Idea does make some sense, for many things, I suppose.

20

Ah! No, please do think ahead - it’s part of why I asked for comment.

I take your point, I think - if an interface, then all sorts of interoperability and flexibility comes along for the ride. e.g. Suppose VPNBOX were indeed another vm (connected by interface) - then it’s all routing. All -gateway needs to know is ‘this traffic’ ‘that way’. Conversely ‘from here’, let it go out clearnet. What the VPNBOX does internally is its business - complexity stays out of whonix.

Easy to add functionality / network capability, easy to remove, easy to constrain, and thus easy to prove ( security / isolation /whatever ).

21

Haven’t lost sight of this, but been sidetracked for a while.

Notes to date:

  • qbittorrent has socks5 settings but they don’t work. They do with ktorrent. At least for my vpn provider. Tested on a kubuntu 14.04 vm, going out via default gw to an openwrt with openvpn connection.
  • have seen note that despite socks5 setting, ktorrent does not use it for udp.
    • this seems born out by netstat / wireshark. I see udp trying to go out directly, not via socks5. (Which seems bizarre, as the whole point of wanting socks5 is to tunnel udp, not just tcp.)
  • curiously, I see no udp traffic reach gw for forwarding (*). Socks5 encapsulates udp within tcp?

'* I very much do not want to enable forwarding on gw, seems much the whole point / safeguard of whonix, having forwarding off.

Puzzled as to how best to proxy / forward these ‘excepted’ packets, though. rinet, socat, dante, mod_proxy, or squid, seem to be candidates, but it seems prudent to be the least whonix invasive possible.

e.g. It feels like a socks5 proxy on gw, since vpn is set up there / whonix is ‘invaded’ anyways, seems appropriate, but seems problematic to corral / identify which ws traffic so qualifies. i.e. with a known src/dst ip and dst port, candidate traffic is qualified. Without such, no way for gw to know which to treat regularly and which to except.

A model seems to be to watch the 9050 treatment, where I guess tor is tracking and doing the de/nat’ting, but not sure rinet has such capabilities.

Thoughts welcome.

22

Related [a “connect to other anonymity network than Tor directly” modification for Whonix-Gateway], FYI:

killyourtv managed to set up an I2PBOX. I.e. installing I2P
on the gateway and accessing it from the workstation. So users would be
using I2P directly rather than tunneling I2P through Tor.

I2PBOX - user → i2p → destination

[ without i2p over Tor (user → Tor → i2p → destination) ]