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

[Yawning Angel]

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

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

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?

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

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

> 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

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.

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.

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/20150723/3170d6e3/attachment.sig>