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

[Jacob Appelbaum]

On 7/24/15, Yawning Angel <yawning at schwanenlied.me> wrote:
> 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.

I think in all cases - a person should signal intent and we should
automate things. A relay once required contacting Roger by hand -
eventually it self-tested and now it is mostly automatic with one
small stumbling block.

>
> 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.
>

I think it is orthogonal - we should be so lucky as to have too many
relays that are awful in the network. That is not the core problem, I
think. The core problem is that when someone wants to help, we don't
make it frictionless - we load them with guilt about learning weird
and sometimes obtuse stuff that is in my view unnecessary.

> [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.

That is good to hear - I agree that some routers will probably not
work. I think it would be great to get some numbers and other data on
those failure modes.

>
> 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.
>

Ok. I understand.

> [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).

To be clear - I think the library code is awful too. This is partially
why I suggested we fork it and ship a fork. This is what the Vidalia
GUI did - they just didn't do the NAT-PMP part of the task.
Ironically, I think nearly no one every complained about that breaking
their routers or anything horrible. I wonder if anyone uses that code
anymore?

>
> 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'd like to say that I think informed consent here is good but also a
strange thing. It feels like we should remember that Free Software
comes with no warranty. That means that it may melt their home router
or scare their cat. Hopefully it merely maps a port. :-)

>
>> 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 I grok you now - the key thing I missed was the worry about
flash proxies.

>
>  * 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).

Ok.

>  * 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 think you are right - I'd even advocate for a bit of go-seccomp -
thus ensuring that the code is reasonably sandboxed. Along some MAC of
some kind like AppArmor or SELinux or seatbelt, I can't imagine that
you aren't perfect by comparison to the other library code.

>
>  * 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).
>

That sounds fine by me -  I think that if that other stuff is done -
it is easy to package it.

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

I agree - we can easily package it for Debian - it could and should
also be part of the other bundles we ship, I think. I guess I can
package it for Debian - I'd like to take a look though before I
commit.

>
>  * 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.

OK. Sounds reasonable.

>
>    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").

Ha. Understood.

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

Agreed.

>  * 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".

Seems reasonable.

>
> I hope this clarifies things.
>

Completely. Thank you.

All the best,
Jake