[tor-dev] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)

[Yawning Angel]

On Fri, 24 Jul 2015 16:21:31 +0000
Jacob Appelbaum <jacob at appelbaum.net> wrote:
[snip]
> > At this point with all the resources available, I will guess that if
> > the user needs something like tor-fw-helper, they probably have no
> > idea what router firmware is.
> >
> 
> Right - but why should they need to know? The goal here is to run say,
> a private bridge for their own use - should we really keep the
> status-quo that is a nightmare to setup?

I have less objections towards people using tor-fw-helper for bridges
than for something like flashproxy or full fledged relays.

Full fledged relays because of stuff like:
https://tor.stackexchange.com/questions/7164/why-do-relays-not-end-idle-tcp-sessions

IMO similar to relays with insufficient bandwidth, relays that can't
connect to any other relay on demand as required (due to a full NAT
table) do bad things to network health.  This is probably an orthogonal
discussion though.

[snip]
> > And again, no.  If they need tor-fw-helper, I doubt they know what
> > firmware is in the first place.
> >
> 
> Right and yet, if they have it, they still have to go through another
> step: using it. I suspect that of our users, we will have zero who use
> it by default; some will choose to use it - this is the really hard
> stumbling point at the moment. Anyone who wants to use it has to
> compile it from source and jump through a lot of hoops before they've
> even tested it against their home router.

Unless their router is *extremely* quirky, the new code will work.  Pain
will start happening if you add lots and lots of mappings depending on
how your router behaves when the uPnP table gets full (since I have to
request infinite duration leases).  NAT-PMP should basically always
work.

Again, this is more a flashproxy issue (since the mapping ideally only
lasts for as long as the Tor Browser session is active) than a relay
one, and we'd want to select a random port at runtime.

[snip]
> Is anyone from support reading this email thread, I wonder? I've cc'ed
> Colin - perhaps he can chime in about supporting a possible usage.
> 
> I think that the primary reason we did not ship tor-fw-helper was to
> punt on the fact that we think the code quality for the *client*
> libraries was awful. That is not the case with your Go implementation.
> Thus, I think we should consider how to either solve the tor-fw-helper
> code (eg: sandbox with seccomp, AppArmor?) or if it is removed, I hope
> we won't take two steps backward by making it even more difficult to
> run a relay, even if a user is perfectly informed and perfectly aware
> of the hubbub around NAT-PMP and UPnP.

Right.  The primary concern when I started my rewrite was the libraries
are really scary (since we were linking against stuff that is part of
the problem on the router end, that make me nervous).

If a user is fully informed about the hazards surrounding uPnP then the
new code is probably a fine replacement (It even has a few extra goodies
that the original doesn't, like dumping the mapping table, and support
for removing mappings).

> I hope I've made my point clear: I really want to see a helper in-tree
> or shipped to end users - even if it isn't *used* by default. I put a
> lot of effort into it once. I can't express enough how demoralizing it
> is that this code has basically never been used and may soon infact be
> rm'ed entirely rather than deployed. Even if it isn't the stuff I
> helped to write, I hope we work to solve this problem for user and not
> to punt - that was always the goal.

Indeed.  The rewrite wasn't exactly easy either.  I think I've done a
poor job of communicating my position, so I'll try to summarize it.

 * I think the new code will work for most people for running a private
   bridge, or relay (though the latter with a consumer grade router may
   be a bad thing for network health).

 * I think the new code is safer than the old code, because it doesn't
   link against 3rd party libraries with "questionable" code quality,
   and is in a memory safe language. YMMV there.

 * I still intend to move the new code from github.com to git.tp.o, and
   am willing to provide things like signed release tags, and tarballs
   of releases if that will make packaging it easier, but I won't be
   the one making packages (unless I happen to get bored enough to put
   it in AUR).

   (And I think "apt-get upgrade tor tor-fw-helper", is a reasonable
    thing to ask of end users.)

 * I have reservations about deploying it as part of Tor Browser for
   use with flashproxy due to poor router side code.  Ultimately this
   is the support team's call, and if they're ok with it, I will do the
   integration work here.

   Most of the really broken (non-security) behavior only happens when
   the uPnP table starts to get full, which is presumably not a concern
   for the bridge/relay use case (Since like aliens from the planet
   Zeist, "There can be only one").

 * If this is deployed to users, they should know that historically
   a lot of routers have had hilariously broken/insecure uPnP
   implementations (Documentation issue).

 * As far as support/bugfixes/maintenance from my end, there's a limit
   to what I can do for quirky/broken routers, and in a lot of cases
   this will end up as "patches accepted".

I hope this clarifies things.

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150724/c657e350/attachment.sig>