So far I have been unable to gain a working torrc and iptables setup for either tor, or, particularly, Tor Browser Bundle. And believe me, I've read, searched and tried - alot. Funnily, many of the security advantages of using Tor are defeated by the need for heavy research and the amount of bad/disnformation out there: Tor is undone by its complications and the lack of clear solutions for heavily secured use.
I would like to be able to run TBB secured with a custom torrc file and iptables policy, but this has proven challenging. Torrc settings and iptables settings for tor itself will not easily translate into TBB, which presents its own specific problems. For examples, TBB does not run as a service as tor does, so it cannot be isolated in iptables in this way. Userspace and namespace methods, where TBB could be run as a dedicated user or in a dedicated namespace, have so far been tried and failed - and I have found no specific workthroughs for this subject. Userspace or namespace isolation would still be ultimately desirable, and this is one thing I would like to see described for this specific purpose. As a result I am left trying to isolate TBB by port, which also requires that I define tor ports in torrc. Defining default ports, those that are known, causes TBB to stop working, solved by redefining different ports. Examining netstat shows that TBB continues to open the default Control Port on 9151 in addition to any newly defined ports. It is currently unclear where TBB is set to do this. Iptables policies of any complexity, providing 'torification' of a system to avoid potential leaks, so far fail with TBB. Policies adapted from those on trac.troproject cause TBB to fail on certain counts, and I am unclear as why certain settings are specified. VirtualAddrNetwork specified in torrc for TBB will produce an unknown host/port response from iptables. The various addresses I have seen specified for LAN or IANA are a mystery to me. TBB seems to be neglected almost entirely in serious discussions of Tor. And yet it is more up-to-date than debian-tor, which currently only offers Obfs3 transports, now somewhat old, in Debian packages, and Meek with some trouble: TBB contains all transports in .py files; it is portable, making it instantly operable in any Debian distro with a few simple (scripted) adjusts, and affording the protection of a 'disposable app', and faster to run than installing Tor and obfs3 on a lacking system, with the Tor Browser only installable via the Tor Launcher package and downloading into debian from the Tor project directly (leaving me unaware of how the browser might be saved for offline installation): TBB can double as a Tor Browser for debian-tor without trouble, but I would still like to be able to run or even adapt to debian-tor) its malleable and rapidly reconfigurable implementation and transports (I assume it might be possible to adapt TBB's .py transports provision to debian-tor, I just don't know how). My chosen solution is to install debian-tor from stored files, adapt transports from the TBB, and use the TBB as a proxy browser for Tor, with additional hardening (lock prefs) if possible. And to run TBB in itself. All require good iptables policies, which has proven a particular challange for TBB. Ideally, what is required is: 1. A clear explanation of how Linux solicits and maintains network connections, particularly with regard to public wifi negotiation. 2. A separation of this basic networking functionality required to maintain router access and of the Tor or TBB processes. 3. A clear explanation of all required allowances in iptables, of Tor, including by port if possible, and including of addresses like those for LAN et al. NAT table routing has proven particularly challenging. 4. A method for running TBB with custom torrc, observing the failure of default port specification (which is part of port securing in custom hashed passwords, etc.) and VirtualAddrNetwork (which I assume is due to TBB's lack of service/daemon functionality. 5. Advice for adapting the transports from TBB to tor. 6. A walkthrough for advanced isolation methods like dedicated user accounts, which have so far proven impossible to run with TBB from a separate account, and network namespaces, which appear to be a potentially powerful isolation solution but which I have not seen adapted to this purpose yet, despite being considerably lighter than complete OS virtualisation/containers. A walkthrough for applying TBB transports to debian-tor would be a bonus. As I say, all my attempts so far to produce a working custom torrc and iptables solution for TBB have not worked (though TBB itself will run with an 'open' clearnet iptables setup), all my attempts to adapt published iptables setups have not worked, and all attempts to isolate TBB particularly behind userspaces have also failed. Namespaces are not something I have yet seen tried for this purpose. A working TBB setup is of course likely more readily adaptable to debian-tor than vice-versa, with a few minor adjustments. As it is I will have to go back to using TAILS for any degree of Tor security until the problems are solved, despite the failings of TAILS in my view (rigidity, lack of programmability in scripting, GUI style, etc.) :/ Any helpful advice would be appreciated. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
