I'm afraid you miss the point. 1. To operate TBB with an attendant IPTables setup, including for reasons of potential leaks, admittedly more of a risk in Torification of other apps. DNS leaks are regarded as a widespread issue, quite apparent in looking into tor configurations, though I personally agree (?) that this smacks of bad programming, perhaps in OS design (though again, this tends to be regarded as more of an issue with diverse proxying). Isolating TBB in iptables has proven problematic, since it lacks a native UID, etc. 2. To operate Tor with the full range of transports: I have started looking at the possibility of operating debian-tor with the transports included in TBB, ie. pointing tor at the pluggable transports and libs in the TBB data and Tor folders, but would love some help with this. This would give the best of both. 3. Further isolating tor or TBB behind a user account, and ultimately a network namespace, which is touted as a light weight container option, but I have not seen documented for this purpose.
Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. -------- Original Message -------- On January 21, 2018 2:13 PM, Wanderingnet <wandering...@protonmail.com> wrote: > 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: > > - A clear explanation of how Linux solicits and maintains network > connections, particularly with regard to public wifi negotiation. > - A separation of this basic networking functionality required to maintain > router access and of the Tor or TBB processes. > - 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. > - 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. > - Advice for adapting the transports from TBB to tor. > - 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 -- 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
