Hardened tor middlebox design, "Tor Bridge Middlebox"

Using a setup very similar to Whonix, a VM tor middlebox only has access to the internet using a USB device. Thus the middlebox retains exclusive access to the USB device and also has a compiled driver. The Host does not have the USB device driver nor anything else that would permit it to connect to the internet.

A second VM runs the Tor Browser (or other tor software as required).

A private virtual network (no gateway, no dhcp) connects the desired online VMs and they cannot communicate with the host nor the clear internet except using the tor socks proxy via the middlebox.

The problem is that tor cannot chain through tor except as a bridge, and when doing so as a bridge, the effective tor circuit length is reduced from three to two nodes because one of the hops is virtual within the same computer between the two VMs.

The other option is to expose a socks proxy on the middlebox that gives access to the clear internet. Thus the Tor Browser or other private VMs with tor can make a full three node tor circuit. Obviously, the opening to the clear internet is a huge weakness.

Ideally, the only way out of the private network should be via the tor on the middlebox. We could call it a “Tor Bridge Middlebox”.

The third way is to hack tor-over-tor or compile the tor code with a change for a four node circuit. Tor-over-tor is not recommended since it would end up being a 5 node circuit which is shown to be worse than 3. Another hack would be tor-over-tor and faking two additional hops on the virtual private network to get a final 3 real node tor circuit, which would be wasteful.

I haven’t found anything related to this yet, except for tor project proposals for “Bridge Guards” in the context of “Bridge Enumeration”, thus I feel that the Whonix project would be best placed to understand the importance of such a setup.

Has there been any discussion of this yet? Any solutions that I missed? (eg corridor is not). I have this all working except I am stuck with either sock5 clearnet proxy on the middlebox or a two-node tor circuit.

I have also posted issue 40093 on the Tor Project for this, please refer to it for more tor specific details. This Whonix current issue has more VM specific information.

Whonix can be built for the RPi so it is a matter of rolling it up and doing custom setups you describe though it is unlikely we have the time or resources to maintain them unless there is a paid support request.

2 Likes

Thank you for your response @HulaHoop, however, maybe I put too much context. I am not looking for support or inclusion of the exact VM setup into Whonix.

The objective was that since Whonix uses a middlebox with tor and it attempts to protect against various identification attacks, it would greatly benefit from a tor Bridge Guard functionality (does not yet exist).

The most concrete example is the current Whonix Tor Browser design. Is it very complex and certainly alot of work to maintain. If tor supported Bridge Guards, then Whonix could simply run the standard Tor Browser in a VM and set it to connect to the Whonix Gateway tor in bridge mode.

In Whonix Gateway:

/etc/tor/torrc
...
ORPort 10.0.2.15:8050
BridgeRelay 1
PublishServerDescriptor 0
BridgeRecordUsageByCountry 0
BridgeDistribution none
AssumeReachable 1
Exitpolicy reject *:*
ExitRelay 0
...

In Tor Browser Whonix Workstation (path just for example):

.../tor-browser/Browser/TorBrowser/Data/Tor/torrc
...
Bridge 10.0.2.15:8050
UseBridges 1
...

That is just one example and would save the Whonix project alot of work, time and maintenance over the long term. The problem at the moment, as I described in my issue, is that such a setup results in effectively only a two node tor circuit since one of the nodes is within the Whonix landscape since tor currently does not support any type of Bridge Guard nor other mechanism that determines that nodes of a circuit are virtual/internal/dummy.

Even further than that, tor support for Bridge Guards would permit Whonix to significantly harden it’s network landscape by closing off absolutely all access to the clearnet except through the tor on Whonix Gateway.

The only paths out of the Whonix environment would be:
Tor Bridge Mode at: 10.0.2.15:8050
Tor Socks5 at: 10.0.2.15:9050

An additional advantage is that each tor instance bridging though the Whonix Gateway could now have it’s own tor settings. Maybe one VM with Tor Browser only exits through a specific country, maybe other opens the control port for specific use.

Derived from the above, another advantage is that the Whonix Gateway tor could now be forbidden to expose a Control Port and only only tor instances bridging out through the Whonix Gateway tor would expose a control port only within the specific VM of interest. Thus all higher risk tor settings would be isolated to specific VMs and would not affect the Whonix Gateway, nor any other VM nor the Host.

Whonix does support connecting to bridges if that’s what you mean.

As for configuring Whonix to host a bridge itself that is a different topic and more complex. It’s not as simple as just switching on bridge hosting and hen having your traffic mixed in with others’, We asked about it before:

[1]

  1. We’d like to clarify that we suspect this defense to be the helpful,
    but it has not yet been conclusively shown to be so, and likely may not
    be in DPI’d bridge and/or low-traffic situations. In fact, after some
    discussion, we suspect that in most cases, other PT’s bridge traffic will
    also be posible to remove from consideration, in ways beyond the simple
    connection matching above. To really have a chance of other traffic
    providing cover, client traffic needs to be mixed with concurrent
    relayed Tor relay traffic, which may require a relatively high speed
    main network relay to happen frequently enough to help.

Hosting a bridge of any type would need port forwarding which isn’t easily done for VM connections since the GW is behind NAT.

If you can find and point to a good set of documentation for it and find the info needed for KVM VM port forwarding then we can add this is an advanced guide to the wiki (assuming you tried it successfully first).

Related info:

[1] [tor-dev] Snowflake server and traffic analysis questions

@Patrick I want to add this reference and related commentary to the wiki. Where can I discuss relays/bridges for cover traffic?

2 Likes

Unfortunately that is not what I mean. This has nothing to do with Tor Bridges as they are commonly used at the moment. The “Tor Bridge Middlebox” would only be a bridge OUT of the Whonix Internal Network (Hence the term MIDDLEBOX), however, I will further avoid the term Bridge to avoid confusion. As previously mentioned, this is not about adding features to Whonix nor to make it more complicated, nor to support new scenarios, but to simplify and harden it within the context of what it already provides. The actual tor feature required does not yet exist in the tor project and has yet to be developed by the tor project, but it would be a huge benefit for Whonix in particular, that is why I feel it is important that the Whonix project understand it and possibly add weight and justification to it being developed.

I will try to explain from a different angle:

Example 1: The Whonix warning about Tor Browser:
Ref: “Do not start Tor Browser in the whonix-ws TemplateVM or whonix-ws-dvm DisposableVM-TemplateVM! It is unexpected behavior and dangerous.” " connections are established if Tor Browser is started in a DVM Template – this risks a compromise of the template and all DisposableVMs based upon it."
http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Tor_Browser/Advanced_Users#tor-launcher
Ideally, the Whonix design should make this situation impossible and the design I proposed above protects against this.

Example 2: Multiple Whonix-Gateway
Multiple Whonix-Gateway are just a workaround and a symptom of the more general problem I am proposing to address. Any single or multiple tor instances on the same IP and same ISP are essentially the same in terms tracking and identification. Within the complete tor framework, there is no real reason to have multiple tor Whonix-Gateways at the same location.
http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Multiple_Whonix-Gateway

Example 3: Clearnet access.
In Whonix, both the Host and the Whonix-Gateway have clearnet access, however, it would be even better if only the Whonix-Gateway had clearnet access. The Host could be offline and the Whonix-Gateway would be the only way out. This of course means that there cannot be “Multiple Whonix-Gateway” (Example 2 above. Exception being multiple network hardware), but multiple Whonix VMs could have their own tor running (own /etc/tor/torrc) which would hop through the single and only Whonix-Gateway out using the existing tor architechture.
Ref: “All Whonix-Gateway ™ and Whonix-Workstation ™ traffic is tunneled through Tor. Host traffic [[95]]uses clearnet”
http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Comparison_with_Others

Example 4: Whonix-Gateway configuration and torrc.
The current Whonix-Gateway setup and torrc has alot of settings and many are hardcoded and limited. What I am proposing would permit the Whonix-Gateway to be much simpler, more flexible and hardened.

I am certain that many members of the Whonix project have more than enough understanding of VMs and Tor to understand what I a proposing. It just that I have to find the best ways to communicate it to avoid confusion with existing terms and scenarios.

tubby-tor via Whonix Forum:

Example 1: The Whonix warning about Tor Browser:
Ref: “Do not start Tor Browser in the whonix-ws TemplateVM or whonix-ws-dvm DisposableVM-TemplateVM! It is unexpected behavior and dangerous.” " connections are established if Tor Browser is started in a DVM Template – this risks a compromise of the template and all DisposableVMs based upon it."
http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Tor_Browser/Advanced_Users#tor-launcher
Ideally, the Whonix design should make this situation impossible and the design I proposed above protects against this.

Seems like mixing different issues. Did you actually use Qubes-Whonix
before? That’s a usability issue. It’s already “impossible” unless user
manually overrides which can’t be by accident and would be a concision
decision and outside threat model.

Example 3: Clearnet access.
In Whonix, both the Host and the Whonix-Gateway have clearnet access, however, it would be even better if only the Whonix-Gateway had clearnet access. The Host could be offline and the Whonix-Gateway would be the only way out.

That would be Whonix-Host.

This of course means that there cannot be “Multiple Whonix-Gateway”

Not necessarily. I just need a way to find on Whonix-Host to allow
network access to VM of type Whonix-Gateway and nothing else.

Example 4: Whonix-Gateway configuration and torrc.
The current Whonix-Gateway setup and torrc has alot of settings and many are hardcoded and limited.

Hardcoded torrc settings? No. You’re free to change any torrc settings.

Either directly if you must due to technical limitation which would be a
bit non-ideal or by using a drop-in. For details on that see:

Limited by what?

I am certain that many members of the Whonix project have more than enough understanding of VMs and Tor to understand what I a proposing.

No, I actually cannot follow much.

1 Like

My current discussion is in the context of a Whonix-KVM environment that I am running sandboxed within my own environment to let me play with and break Whonix, in particular with respects to the tor setup. For example, the Whonix-Gateway Anon Connection Wizard happily connected to my own tor socks5 proxy and thus the Whonix-Worstation Tor Browser was running in a tor-over-tor which I thought Whonix protected against (no problem, I am just playing). Additionally, I can compromise a second Whonix-Workstation sharing the same private network as another Whonix-Workstation at 10.152.152.11 and sniff it’s traffic going to the Whonix-Gateway 10.152.152.10:9050 socks5 proxy because socks5 is not encrypted, thus the VM isolation is compromised and internet and tor usage can be exposed. These are actually the types of compromises that I am trying to find better solutions for. Eg: a VM gets compromised and starts probing the Whonix-Internal, sniffs network traffic, scans for socks5 addresses/ports, find clearnet exits (socks or other), find tor exits (socks or other), find tor control ports, or find other VM holes to bridge out of it’s VM cage, etc…

Yes, Whonix can do anything and there are ways customize the setup to avoid this, but at the same time any distro can do anything with enough work.

Whonix is very good, probably the best packaged distro for security, but there are always ways to improve things. All of my points just above and in the previous posts are simply to try to communicate an interesting future path to leverage tor for Whonix and other similar setups.

If we had tor on Whonix-Workstation 10.152.152.11 using the Whonix-Gateway 10.152.152.10 as a tor bridge out (see my previous posts) and tor built a three hop circuit starting from Whonix-Gateway 10.152.152.10 (assuming it goes out to clearnet), it becomes a better solution (eg. not sniffable, further Whonix-Gateway lockdown, isolating tor configuration )

If this still doesn’t make sense, maybe this deduction will help:

  1. NEWNYM (new circuit) requires a tor control port
  2. It is not safe to expose a tor control port beyond the localhost
  3. The standard Tor Browser includes a new “New Tor Circuit for this Site” which requires a control port
  4. Because of point 2, Whonix-Workstation Tor Browser does not have a “New Tor Circuit for this Site” (point 3), it must be done on the Whonix-Gateway
  5. The Whonix-Workstation Tor Browser connects to the Whonix-Gateway using socks5 not-encrypted (problem, but fixable)
  6. If we want to use a standard Tor Browser in a Whonix-Workstation so that we can “New Tor Circuit for this Site” and to have everything tor encrypted before leaving the localhost, the Whonix-Workstation needs clearnet access for tor (not safe). That is why Whonix does NOT have the standard Tor Browser.
  7. Continuing from point 6, we could make the Tor Browser’s tor use the Whonix-Gateway tor as a bridge out. But Whonix does not because it would reduce the effective circuit hops to 2 instead of 3.

Thus, of course, considering the current state of tor and available options provided by tor, the current Whonix setup is very good. But it doesn’t mean that it could not be improved. And the examples I am using are very specific with the hopes that it is a bit simpler and clearer, but the actual useful of such an approach is much larger.

And, sorry in advance if none of this seems useful to Whonix, I will simply close the issue if there is no interest.

Then Example 1 is not applicable

I see. Well, there’s a lot ways inventive users can do things recommended against. If users get such ideas I don’t think it’s worth complicating Whonix setup to prevent them from doing that. Certainly not something recommended in Whonix documentation or happening by accident.

I wonder how that impression was created.

Tor over Tor prevention is for applications running from inside the workstation but it’s not 100% guaranteed. (An application installed from outside Debian package sources might bundle it’s own Tor binary and run Tor on a non-standard port. That connection wouldn’t be prevented.)

A long standing issue for Non-Qubes-Whonix. Documented here:

Qubes and Qubes-Whonix do that. Each workstation VM is connected through it’s own vif+ network. That would be nice to have but I wouldn’t know how to implement this due to virtualizer limitations. It would have to be scripted on the host. I.e. Whonix-Host first. Basically re-inventing Qubes.

I don’t think it’s realistic / a good approach to fiddle with the application level (modify Tor). These known issues are network level issues and have to be fixed there.

Let’s suppose Tor was running as of nowadays inside VM1, have to go through VM2 where corridor is running: That would still not survive VM1 compromise due to Tor’s ability to figure out it’s own real, external IP address through Tor control protocol command getinfo address.

1 Like

@Patrick Thank you for those answers. I completely agree, the strongest and key point is that more isolation (virutal, physical, etc) can protect against more risks. That was missing from my previous discussions and it is always the best way to increase protection.

What still bugs me is that even though tor always has to assume that everything is hostile, we can’t take advantage of that within private networks (Physical LAN or VM). We even have to reduce functionalities such as dropping view circuit and NEWNYM from the Tor Browser.

Additionally, I am still stuck if I want to sandbox a working tor. Maybe the only final way will be tor-over-tor with additional mitigating functionalities against the tor-over-tor risks?

For example (just one example), if I want to run a full standard Tor Browser, but sandbox it properly (even assuming as far as physical hardware), if it is doing tor-over-tor, all it knows is the exit node IP of the underlying cuircuit. What remains is to obfuscate the first underlying tor circuit communications so that the second one can’t be correlated with the first one, even if the second circuit goes over one or more same nodes as the first. Are there any discussion within Whonix somewhere in that direction? or anything related to sandboxing a working tor by any other method within the Whonix landscape?

None.

@Patrick Additionally, you are correct in your previous response that the above design I proposed of the “Tor Bridge Middlebox” could give the isolated VM the identifying IP address since the isolated VM would know all the IP addresses of all the nodes in the circuit, including the bridge out. Thus, the “Tor Bridge Middlebox” clearnet IP would have to be hidden, only providing the internal network IP to the requesting tor client in the isolated VM. As you mention, this further complicates the tor software and would have very low usage and thus is high risk for software bugs and unforeseen consequences and risks.

Thus, the only option I see remaining is tor-over-tor. I would like to make a precision to tor-over-tor that I haven’t seen elsewhere.

There are two general types of tor-over-tor.

More specifically a tor-to-tor, which is of course very dangerous because the true traffic would come out of the first three-hop tor circuit through a tor exit node to then go back into the tor network trough another server (possibly controlled or related to the origin, or even worse, the originating computer) to then be sent over the tor network again.

The second is a tor-wrapped-tor (or tor-in-tor) where the second three node tor circuit is going through the first three node tor circuit. Thus, the first exit node only sees a connection back to the tor network and the contents seen by the first exit node is triple encrypted by the second tor circuit.

If the assumption is that the isolated VM could be compromised, then origin based correlation attacks would already be possible, thus I don’t see how a tor-wrapped-tor would increase any risks. But I will have to further think about this and test it.

Thank you @Patrick and @HulaHoop for your insightful responses.