On Thu, 23 Jul 2015 23:46:26 +0000 Jacob Appelbaum <jacob@xxxxxxxxxxxxx> 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
Attachment:
pgprscBETtKkK.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev