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

[Yawning Angel]

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.

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.

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.

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

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

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/20150724/4ab12ba4/attachment.sig>