[tor-talk] TBB advantages in VM
Abel Luck
abel at guardianproject.info
Fri Sep 28 02:18:39 UTC 2012
adrelanos:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20120928/2d11bce4/attachment.pgp>
More information about the tor-talk
mailing list