On Fri, 24 Jul 2015 16:21:31 +0000
Jacob Appelbaum <jacob@xxxxxxxxxxxxx> 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
Attachment:
pgp0942K0vYel.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev