Does using Tor Browser in Whonix leave less traces than just running Tor Browser on the host? Running a whole virtual OS should create more network traffic than just Tor Browser. On top of that there’s always network traffic from the host. How can all non-Whonix traffic on the host be blocked when using Whonix?
What measures can be taken against VM OS-generated network traffic that has nothing to do with the purpose of any particular Whonix or Tor session? I’m aware of stream isolation, but can that cover everything? The OS can surely generate more network traffic streams than the number of circuits that stream isolation affords.
I didn’t think that’s also a problem with Qubes, where the host doesn’t even have networking AFAIK.
You make it sound like there’s a piece of software called corridor, but I haven’t found anything.
I guess you don’t mean configuring this in the virtualization software, where bridging is also available.
I’m not sure how that would be done. There are lots of services and I don’t have an overview of what they are, what they are doing or how to monitor if new ones may start.
Depends on the OS you use. For a standard install of the average linux distro most relevant stuff I can think of is ntp, maybe automatic updates, systemd afaik does some name resolution using google dns. For windows there is certainly more to block.
There is a bridged option for virtualbox or kvm, the latter one also having macvtap. I was also thinking of PCI passthrough like qubes does which, to admit, is not really a bridge.
Yeah unfortunately true. I think we got it though becuase this systemd service s disabled? I don’t know what Debian does but I know they always like privacy preserving defaults. Also why in the world did the systemd authors choose this???
Shouldn’t OS-generated network traffic (host or guest) be a major point of concern when using any kind of anonymity tool? It doesn’t seem very likely that a problem of such scope has never been approached, discussed or researched somewhere. Isn’t this part of the threat model not only of Whonix, but of Tor, etc?
Unsolicited network traffic should be a major point of concern when using any OS, period. This isn’t an issue that’s limited to Whonix users so any such traffic should be stopped upstream if possible. Lack of concern for this is why Whonix discourages using Windows or Ubuntu.
Not Tor. Tor’s job is to provide anonymous routing for your traffic, not to discriminate between the type of traffic that it routes.
Not Tor Browser either. Tor Browser’s job is to provide identical fingerprints to destination websites. What the OS does is beyond TBB’s scope.
These issues should only be addressed by Whonix if ignored upstream.
Seems that the vulnerability due to OS traffic would be potential tracking of hardware as it moves between locations. In most cases, this isn’t catastrophic because of the location anonymity that Tor provides. Can you be more specific about your threat model?
I see traffic fingerprinting as a major threat. Each OS and each configuration will I imagine generate a unique network traffic fingerprint. The attacker has to keep an eye on the servers an OS is likely to connect to and inspect the traffic. A good countermeasure example is onionizing software repositories because software updates make you identifiable.
Shouldn’t OS-generated network traffic (host or guest) be a major point of concern when using any kind of anonymity tool? It doesn’t seem very likely that a problem of such scope has never been approached, discussed or researched somewhere. Isn’t this part of the threat model not only of Whonix, but of Tor, etc?
The closer you look, the more things you find. There is an army of
people working on tracking. Backed by companies and governments having
available trillions of money. The privacy community is small in comparison.
Whonix 13 systemd version does not have the fallback DNS feature.
Whonix 13 does not use systemd-resolved.
The fallback DNS wouldn’t work anyhow, because: Tor - Whonix
So minor concern for Whonix.
But indeed a frightening development in Debian. I don’t think enough
Debian developers have noticed this yet. It’s a wider policy discussion
for debian-devel and hopefully not just up to the systemd maintainers.