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

Fri Jul 24 16:21:31 UTC 2015

On 7/24/15, Yawning Angel <yawning at schwanenlied.me> wrote:
> On Thu, 23 Jul 2015 23:46:26 +0000
> Jacob Appelbaum <jacob at appelbaum.net> wrote:
>
> [snip]
>> > Do users know that their router's implementation of NAT-PMP/uPnP is
>> > shit?
>>
>> Who knows better than the user? And who better than the user to take
>> an action and to learn it?
>
> 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?

> Eg: https://portforward.com
>
> [snip]
>> I don't even understand why this is part of the discussion? Why is
>> this our problem? Or put differently - sure, people don't patch their
>> stuff - are we really making the problem worse? Wouldn't it make them
>> more likely to interact with their router and perhaps apply patches to
>> it?
>
> Dunno.  Considering there was a bunch of fuss in the media about "you
> should disable UPnP to increase security" a while ago, we could be
> making things worse.
>

I don't think so - I think that if we care to take a specific position
on the security fuss around UPnP, we could ship a tool that disables
or alerts users to the issue. Otherwise, we can consider that the
internet is supposed to be end-to-end and that that fuss is mostly
hoping to make running a Tor relay from home impossible.

> Eg:
> http://www.forbes.com/sites/andygreenberg/2013/01/29/disable-a-protocol-called-upnp-on-your-router-now-to-avoid-a-serious-set-of-security-bugs/
>
> 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.

> [snip]
>> > If they think they can/want to support this sort of thing, then they
>> > can say so, and I'll do the integration work on the Tor Browser
>> > side, and write the required flashproxy changes to make it work for
>> > more than ~2 hours when using NAT-PMP.
>> >
>>
>> That seems awesome - I guess I'd ask - does it need to be on by
>> default? I'm not actually advocating for using it by default - I am
>> advocating for shipping some NAT punching tool that can be used at
>> all. tor-fw-helper never shipped as compiled code to end users which I
>> found to be extremely demotivating.
>
> For flashproxy to work, yes, it would need to be on since flashproxy
> currently requires NAT traversal.  WebRTC will also fix this, but a
> version of flashproxy that uses WebRTC does not exist yet.
>
> [snip]

I think this conflates two issues - issue one is a general
tor-fw-helper program and another is putting it to use. I don't have a
real position on using it by default - I think that is something that
needs a discussion. I take a position on having a binary shipping -
where a user may choose to use it or not use it. We were one step away
from that - tor-fw-helper builds everywhere tor builds - it was just
not compiled by default at build time.

>> >> Any user that can compile a Go program can probably just do the NAT
>> >> punching on their own anyway...
>> >
>> > $ go get github.com/yawning/tor-fw-helper
>> > $ $GOPATH/bin/tor-fw-helper
>> >
>>
>> I can't tell if you're agreeing with me here or if you are suggesting
>> that people who have trouble configuring a program to use to a SOCKS
>> proxy will be able to build and use a commandline tool. I assure you -
>> nearly anyone who can use `go get` will be able to configure their NAT
>> manually. For everyone else, we need some usable automation.
>
> A bit of both.  In my opinion, people that can't setup port forwarding
> by hand shouldn't be running a Tor relay in the first place.

I understand that view.

What if the only interface is UPnP and NAT-PMP? How should I do that
by hand? Tor has the timer code as well as the tool - "doing it by
hand" means editing the torrc in that case, no?

Usually when I need NAT-PMP - I do the above and those Apple router
devices most certainly do not have a generic web interface - so the
only way to do it is with non-free Apple tools or with a tor-fw-helper
or similar tool.

>
>> > There are no dependencies beyond what is provided by the Go
>> > compiler, so it's the easiest thing to package ever. If someone
>> > wants to package binaries for it, I don't care. I'll even add a
>> > manpage for it once the upstream git repo is move to
>> > git.torproject.org, tag/sign releases, and keep tarballs around if
>> > that's what people want.
>>
>> Seems reasonable. I had hoped it would be part of the default Tor
>> build process - so anyone with a Tor can be a NAT punching relay or
>> bridge or pluggable transport. We were very close to this with
>> tor-fw-helper but never flipped the switch. It would be pretty sad if
>> we went even further away from this much needed ability. I guess that
>> is the direction of travel though. :(
>>
>> >
>> > However, if it breaks, my response will be "patches accepted" for
>> > all but the most trivial bugs since it's not realistic for me to
>> > own every single router ever made.  And more importantly,
>> > compromised routers due to shitty/out of date uPnP implementations
>> > are Not My Problem.
>>
>> If we shipped it, I'd say we're still improving on nearly every front
>> over the C tor-fw-helper situation.
>
> If that's what people want to do.  They should let me know so I
> sign/tag releases and add the documentation.  Unless someone from the
> support people tells me they're ok with dealing with supporting users
> when this fails, I won't do the flashproxy work, but someone else is
> more than welcome to do it.

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.

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.

All the best,
Jacob