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

[Jacob Appelbaum]

On 7/23/15, Yawning Angel <yawning at schwanenlied.me> wrote:
> On Thu, 23 Jul 2015 19:18:34 +0000
> Jacob Appelbaum <jacob at appelbaum.net> wrote:
>
>> Why are we avoiding allowing users to make this choice because of the
>> above reasons? If a user wants to run a relay or a bridge, we should
>> make it easy. We don't answer the above questions when it is hard -
>> are we really off the hook there? It just seems ridiculous.
>
> 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?

> It's more a uPnP issue, but I found bugs in at least one NAT-PMP
> implementation when writing the code (fixed in upstream, don't know how
> many people are running the newer code).

Lots of NAT punching server side code is buggy for sure - I don't
think we disagree.

> Utterly horrific behavior especially in uPnP implementations is a well
> known and well documented problem.
>
> Eg:
>  * http://www.upnp-hacks.org/annoyances.html
>  * https://tools.ietf.org/html/rfc6886 (Sec. 9.5)
>  *
> https://community.rapid7.com/servlet/JiveServlet/download/2150-1-16596/SecurityFlawsUPnP.pdf

I again, agree that this is all problematic.

>
> While the situation has probably improved over the years, having users
> use a feature on their router that should be off until the router
> firmware is known not to be horrible (See the report on RCE
> vulnerabilities) doesn't feel great to me.  How many average users keep
> their router firmware up to date?
>

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?

> [snippity]
>
>> > But we have a gigantic userbase, and playing "consumer router
>> > support technician" for all of the ones that ship with broken
>> > uPnP/NAT-PMP implementations does not fill me with warm fuzzy
>> > feelings.
>>
>> I think this is a weird analysis. How many of those people even try to
>> be a relay or a bridge? Do we have numbers on that? Does the support
>> team object or are you objecting on their behalf? It just seems too
>> hand wavy for too many years to punt on dealing with NAT properly.
>
> I briefly spoke to Lunar about this at Valencia when I was asked why,
> given a rewrite exists that it's not being shipped with flashproxy.  I
> was less focused on the relay side of things and more on flashproxy
> specific issues, which I'm still convinced will be Not Fun to support.
>
> 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.

>> I admit, I am pretty frustrated that we implemented it, shipped the
>> code for years and I'm probably the only person who really used it
>> because of what feels like fear, uncertainty and doubt. Some of the
>> concerns makes sense but it mostly just strikes me as a farce at this
>> point. We can always make it harder later but we haven't really tried
>> to make it easier, ever.
>
> Part of this sounds like a documentation issue.
>

I don't agree - the history is that everyone hated the libraries that
were used and Tor is (correctly) an extremely conservative culture
when it comes to software design. Sadly, attempts to fork and include
the needed code were totally shot down - so it meant that it was a
rarely used compile time option used by approximately, I'd guess, me.

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

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

All the best,
Jacob