Whonix-Workstation Firewall - VPN_FIREWALL feature - design discussion

Development
1

It somewhat clashes with Whonix’s stream isolation design. (Stream Isolation)
The issue is documented here:
Combining Tunnels with Tor

There is an idea to simplify this:
https://phabricator.whonix.org/T142

I got a local git branch, that implements the VPN_FIREWALL feature in Whonix-Workstation Firewall. But it currently breaks applications, that are configured to use a SocksPort.

Let’s take for example XChat. How should XChat connect when VPN_FIREWALL has been enabled on Whonix-Workstation? Certainly, user → Tor → destination would be wrong? So best VPN_FIREWALL could do for now is cutting off its internet access until XChat gets configured to use “no proxy”, i.e. “use system defaults”, which would go through the VPN, i.e. then it would go user → Tor → VPN → destination. (Setting to “no proxy” for VPN users could be done at a later point and is not part of this issue. Much later.)

But what about a few other “likely-fingerprintable-if-using-the-same-Tor-or-VPN-exit” connections? Such as:

  • whonixcheck: Tor SocksPort Test (documented here: systemcheck - Security Check Application)
  • whonixcheck: Tor Browser Update Check
  • whonixcheck: Whonix News Check
  • tb-updater: Tor Browser Download
  • sdwdate

Should those go user → Tor → VPN → destination? Or just user → Tor → destination?

What speaks against letting them exit through the VPN (user → Tor → VPN → destination)? Then the VPN might be able to identify the user as a Whonix user.

What speaks against those not going through the VPN (user → Tor → destination)? Some users add the VPNs for eventual better anonymity/privacy/security. (Eventual as in, it’s not part of this topic, see: also TorPlusVPN · Wiki · Legacy / Trac · GitLab) Those users would expect the VPN to be always used and would not worry about fingerprinting so much. Skipping the VPN would be unexpected.

Both defaults would be bad.

At the moment I think it would be best to cut off all Tor SocksPort access by default, i.e. make sure applications not configured to use a Tor SocksPort, i.e. configured to use system defaults would result in using user → Tor → VPN → destination and everything else (XChat still configured to use a Tor SocksPort, whonixcheck, tb-updater) would just fail closed. And then give an option (or as a mid term solution just documentation) on how users can allow direct Tor SocksPort (i.e. user → Tor > destination) exceptions. And another option (or as a mid term solution just documentation), on how to configure the “likely-fingerprintable-if-using-the-same-Tor-or-VPN-exit” applications to not use a proxy, i.e. so they also use user → Tor → VPN → destination?

Except for sdwdate. Since it will only use Tor Hidden Services in Whonix 10, there is no way to make it exit through VPNs.

Ticket:
https://phabricator.whonix.org/T158

Thoughts?

2

I might be repeating the gist of your post but here is how I see things. It is a complex subject.

All whonix related packages and updaters, strictly the packages with whonix in their name should always use Tor only and directly. There is no benefit I can see from driving them through a VPN and they will cause the user to be fingerprinted.

The rest of the packages shipped with Whonix like xchat should only use VPN if selected to do so.
Say someone turns on the VPN firewall feature, it would prompt the user to choose which internet facing programs shipped with Whonix they would like to exempt from Tor socks.

As for anything extra they install, it probably isn’t configured to use stream isolation anyway and so they will be redirected into the VPN. For this just put a note that other applications that aren’t using uwt will by default be using the VPN.

3

Related question, is it difficult or impossible to configure outside software on the fly to use stream isolation?

4

I don’t think there is a socksifier that works that well yet. It’s on a by case base. (Ex: not much point socksifing an apache web server.) Probably not feasible.

5

Yes, complex topic indeed.

All whonix related packages and updaters, strictly the packages with whonix in their name should always use Tor only and directly. There is no benefit I can see from driving them through a VPN and they will cause the user to be fingerprinted.
The argument of many is, longer chain, better security.

Or excempt from VPN?

That grade of usability is left for later. Much later.

As for anything extra they install, it probably isn't configured to use stream isolation anyway and so they will be redirected into the VPN. For this just put a note that other applications that aren't using uwt will by default be using the VPN.
That is something that could be added here: https://phabricator.whonix.org/T142
6
The argument of many is, longer chain, better security

That’s a wrong argument. Users should be educated on misleading ideas. VPNs are not sophisticated enough to deploy defences against traffic analysis, they are a simple SSL connection and are easily fingerprinted. They are a way to get around Tor exit bans at best, and that could be useful. But they don’t add extra anonymity protection from dragnet surveillance.

If the security facts are thought over, you will see Whonix specific packages shouldn’t use vpns because they won’t be getting any extra security, they’ll omake wave a large red flag to the operator that so and so is a Whonix user.

Or excempt from VPN?

Whichever makes more sense programatically. Same effect.

7

[quote=“mitm, post:6, topic:886”]That’s a wrong argument. Users should be educated on misleading ideas. VPNs are not sophisticated enough to deploy defences against traffic analysis, they are a simple SSL connection and are easily fingerprinted. They are a way to get around Tor exit bans at best, and that could be useful. But they don’t add extra anonymity protection from dragnet surveillance.

If the security facts are thought over, you will see Whonix specific packages shouldn’t use vpns because they won’t be getting any extra security, they’ll omake wave a large red flag to the operator that so and so is a Whonix user.[/quote]
Well, it’s not my argument. So I am not going to defend it. But a very common one. Perhaps I should have said that. That’s a different discussion with very diverse opinions. One, that I am not eager to have. A summary is here TorPlusVPN · Wiki · Legacy / Trac · GitLab and it has been discussed recently on the tor-talk mailing list. I don’t feel appointed to end this discussion and to defend a final, totalitarian standpoint that post-Tor-VPNs are always useless or even counterproductive for better anonymity/security/privacy in all cases. If someone, ideally knowing all this, disagrees with me, wants to use a post-Tor-VPN, fine. Then I don’t want to include any technical hurdles preventing them.

8

Yes I know its not your argument. All I was saying is you should present research papers like the one I linked to provide fact based advice.

I found a list of good free software socksifiers. Tun2socks and torsocks maybe others are good for system wide.

https://en.wikipedia.org/wiki/Comparison_of_proxifiers#Proxy_protocols_and_methods

9

Do you find any of the socksifiers good enough for an automatic way to anonymize custom insyalled packages on demand?

10

A lot from this list are proprietary, outdated or unmaintained. I don’t think there is a holy grale in custom package automatic socksification for stream isolation yet.

In context of stream isolation, it makes it is not useful to socksify the system wide, the whole system - because then all would go through the same Tor SocksPort - identity would correlate - what stream isolation is preventing.

If you want to socksify the whole system, i.e. user → Tor → proxy → destination [except for pre-configured applications using a Tor SocksPort, same discrepancy] I found redsocks useful. (Doesn’t help with stream isolation.) It’s somewhat documented here:

Related, “ProxyBOX”:

11

Can uwt ever be automated? What about Tor do they plan on adding automatic stream isolation to every new connection detected?

12

It’s not on the horizon, doesn’t look like, but no one knows with what great ideas and code someone comes up with.

I don’t think so. The closest they provide is IsolateDestPort and IsolateDestAddr but it is recommended against enabling this by default. At the level on which Tor is operating, it’s not possible to reliably distinguish by application.

13

On Android there is an app that’s a wrapper around scripts written by Mike Perry. It forces selected apps through Tor and can make bypass exceptions for the Orbot transparent proxy. Would Mike’s scripts work on Debian with some modification?

What I’m looking for here is an easy way for Whonix users to configure exceptions to the VPN tunnel when its running, forcing them thru Tor instead.

https://people.torproject.org/~mikeperry/android-hardening/android-firewall.zip

How to Limit network access by user / group using iptables - Owner Match | Linux Blog (iptables module: ipt_owner )

orwall.org

“The redirection is based on the application user id. Each android application runs as a dedicated user, and iptables has support for traffic filtering based on the process owner, meaning it’s really easy and pretty safe to do this kind of thing on an Android device.”

14

A user similar to the “clearnet” user would be easy to implement. Similar to this:

Then that user “noforce” or however it call it?

Then that user use Tor SocksPorts. System DNS (Tor’s TransPort) might be more difficult. (Remotely related: Whonix-Gateway System DNS - Whonix)

15

+1

I was thinking “bypassvpn” for a name?

16

I would like to prevent “vpn” in its name. Because in long term that feature is probably not tied to vpn. From perspective of iptables, it doesn’t really understand anything about vpn.

17

Good forward thinking. Then the name you picked is the best one I can see.

18

[quote=“Patrick, post:12, topic:886”][quote author=mitm link=topic=976.msg7098#msg7098 date=1424824680]
Can uwt ever be automated?
[/quote]
It’s not on the horizon, doesn’t look like, but no one knows with what great ideas and code someone comes up with.

I don’t think so. The closest they provide is IsolateDestPort and IsolateDestAddr but it is recommended against enabling this by default. At the level on which Tor is operating, it’s not possible to reliably distinguish by application.[/quote]

There is a well reasoned post about this on the TAILS site:

https://tails.boum.org/contribute/design/stream_isolation/

Summarizing:

IsolateDestPort is good for a chat client that has multiple accounts, spreading the streams would thwart attempts to correlate names across networks.

IsolateDestAddr is good for web browsers, given that there are multiple TCP streams generated when one loads a web page it would be a negative to use IsolateDestPort, self-flagging as a traffic source using the IsolateDestAddr feature.

I strongly recommend reading their page, it’s not long and the writing is much clearer than what I’ve produced here. This is how they implemented the principles - separate SOCKS5 ports based on the type of application using them.

Default SocksPort

SocksPort 127.0.0.1:9050 IsolateDestAddr IsolateDestPort

SocksPort for the MUA

SocksPort 127.0.0.1:9061 IsolateDestAddr

SocksPort for Tails-specific applications

SocksPort 127.0.0.1:9062 IsolateDestAddr IsolateDestPort

SocksPort for the default web browser

SocksPort 127.0.0.1:9150

19

@killswitch this is very off the original topic. And the quote markup is broken.

Back the the original question:

I am working on this at the moment. Still not clear how to best implement it. Trying to adhere the principle of the least surprise. What tunnel lovers want in this case is user → Tor → tunnel → destination to have a longer tunnel length. Once they made the decision, then they want it. I don’t want to rehash the actual positive or negative effects on anonymity. They want this most likely without having thought through too much of the Whonix specifics. That’s the thing the user decided, so I don’t want to go back through discussion the previous stuff at this point.

So I conclude, that it would be best to disallow any local socksified connections [circumventing the tunnel] by default. Unable to connect by default when VPN_FIREWALL=1 inside workstation:

(a)

  • whonixcheck SocksPort test
  • whonixcheck Whonix News Check
  • Tor Browser Downloader by Whonix developers

(b)

  • default uwt wrapped applications (curl, wget, ssh, gpg, …) as per list ( Stream Isolation )
  • default proxy settings applications (Tor Browser, XChat, …) as per list ^

There is already documentation on how to make these applications work again, i.e. to (b) use the system default. I.e. how to make them go user → Tor → tunnel → destination.
Here:
Connecting to Tor before a VPN
And here
Connecting to Tor before a Proxy

X: As for (a) I can add instructions on how to make them work again also. I.e. how to make them user → Tor → tunnel → destination. Not hard and already possible. Just needs configuration and documentation.

Y: Optionally, it also would not be too hard to modify /usr/bin/whonix_firewall to make those go user → Tor → destination. I think for the first iteration it will be required to modify /usr/bin/whonix_firewall on the workstation to make those go those go user → Tor → destination. If that gets a popular use case, that can get a config option.

All of that stuff will be documented on the related sub pages of Combining Tunnels with Tor anyhow. It probably always will be complex, but this lies in the nature of the subject.

What I am unsure about at the moment are two things.

  • sdwdate: Cannot be configured to go user → Tor → tunnel → destination because it connects to Tor hidden services only. I think allowing user sdwdate to connect even if VPN_FIREWALL=1 could be okay okay. Could be mentioned in the documentation, and how to disable sdwdate. Or would it be better to have it fail by default and then let users opt-in to have it go user → Tor → destination only?

  • control port filter proxy access: When VPN_FIREWALL=1 in the workstation, the workstation should still be allowed to access the gateway cpfp? Tor Browser (using the VPN then) sending signal newnym would have no the expected effect. Signal newnym generally would only effect applications to “only” got user → Tor → destination. whonixcheck Tor bootstrap test would still be useful (requires cpfp access). Perhaps connection failing by default, with opt-in to enable also?

20

I agree with this. I think the Whonix-specific packages and updaters should go through Tor only. I think there should be an option notification and selection panel to go over Tor or VPN for XChat / Pidgin / the other specifically-configured apps that have a high probability of fingerprinting. When VPN_FIREWALL is configured, all OTHER apps (those not specifically bundled or configured for TransPort usage) should default to user -> Tor -> VPN -> destination.