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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk