[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] TBB advantages in VM

> Abel Luck:
>> Hi,
>> Given the following conditions:
>> 1) Firefox (15.0 lets say) is running in an isolated VM, and only
>> Firefox is running (i.e., no other user apps)
> Bad. You'd be one of the very few people not using TBB. There are much
> more TBB users than Mozilla Firefox + Tor users. You can only be
> anonymous in a big groups, so don't put yourself into a smaller group.

Yup, my thoughts too. The uniform fingerprint is one of TBBs great assets.

>> 2) The VM is being properly transparently proxied by another machine
>> running tor in transparent proxy mode
> Answered below.
>> 3) The proxy machine fails cosed upon Tor exit/disconnect
> Good.
>> What are the benefits to running the TBB, specifically, what are the
>> benefits of the patched Firefox+TorButton?
> You're lucky, I've been working on something similar for a while. [1]
> Tor Browser without Vidalia/Tor is used in Whonix on one machine. Tor is
> running on another machine. Both machines are connected through an
> internal network. Also fails closed. (The machine running Tor has two
> network cards.) Tor Browser is configured to use a SocksPort listening
> on the machine with Tor.
> That is the same what you describe, just simpler. (No need to patch
> TBB/Firefox, beside the TBB startup script.)
> The startup script was modified only start Tor Browser, not Vidalia and
> Tor. (Tor Browser = patched Firefox + Tor Button)

Ah good idea :) I was thinking about compiling the patched Firefox
myself, but hacking the startup script is much easier heh. Gonna steal
this one.. thanks.

> Advantages:
> - Firefox proxy bypass bugs (ex: [2]) was circumvented.
> - More advantages... [3]
> Disadvantages.
> - higher hardware requirements
> - more difficult to set up
> - ... [4]
> Security comparison... [5] Attacks comparison... [6]
>> My first thoughts are:
>> * Identity correlation through circuit sharing is eliminated (TBB uses
>> its own tor circuits)
> I'd rather recommend an isolated proxy design (Two machines, one runs
> Tor, another one runs Tor Browser. Tor Browser can only access Socks
> ports on the machine with Tor.), instead of a transparent proxy design.
> Otherwise operating system updates (and other applications, software
> updater you are not aware off) still use the same circuit.

While that is a good idea, it's not relevant to my use case, see below.

>> * Uniform Firefox fingerprint to blend in with other tor users
> No, answered in my first sentence above.
> [1] https://sourceforge.net/p/whonix/wiki/Home/
> [2]
> https://blog.torproject.org/blog/firefox-security-bug-proxy-bypass-current-tbbs
> [3]
> https://sourceforge.net/p/whonix/wiki/Security/#whonix-security-in-real-world
> [4] https://sourceforge.net/p/whonix/wiki/Security/#disadvantages-of-whonix
> [5]
> https://sourceforge.net/p/whonix/wiki/Security/#comparison-of-whonix-tails-and-tbb
> [6] https://sourceforge.net/p/whonix/wiki/Security/#attacks

Interesting reading, thanks! My use case is different. It's running
Qubes-OS [1] with a specific TorVM acting as a transparent proxy for
other AppVms.

The AnonBrowserVM is a VM that only has Firefox (soon TBB without tor).
OS updates are handled separately in a different VM. The root FS is
read-only (technically COW, but never written, see [2]).

Looking at your attack comparison matrix, I believe a proper Qubes
w/TorVM+AnonAppVM setup is safe for all attacks except those involving a
vm exploit and an attack against the tor process or network.

[1]: http://qubes-os.org
[2]: http://wiki.qubes-os.org/trac/wiki/TemplateImplementation

Attachment: signature.asc
Description: OpenPGP digital signature

tor-talk mailing list