On 7/24/15, Yawning Angel <[email protected]> wrote: > On Thu, 23 Jul 2015 23:46:26 +0000 > Jacob Appelbaum <[email protected]> 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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
