Re: [tor-dev] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
On 7/24/15, Yawning Angel wrote: > ... > I have less objections towards people using tor-fw-helper for bridges > than for something like flashproxy or full fledged relays. > ... > IMO similar to relays with insufficient bandwidth, relays that can't > connect to any other relay on demand as required (due to a full NAT > table) do bad things to network health. This is probably an orthogonal > discussion though. loudly agree: UPnP for bridges or flashproxy, maybe - NOT relays! UPnP exposed in a poor implementation is opening up users of a Tor instance behind it to various types of attack. it is *worse than nothing*. the Rapid7 research did not cover *all* of the *existing* severe vulnerabilities in UPnP as commonly implemented by router vendors. command injection means even if libs are used properly, a poor implementation may call those interfaces incorrectly. i can provide horror stories, if skeptics remain. > Right. The primary concern when I started my rewrite was the libraries > are really scary (since we were linking against stuff that is part of > the problem on the router end, that make me nervous). what Yawning isn't saying, is that those old libs are full of exploitable vulnerabilities. i only hate on libpurple harder ;) > * I think the new code will work for most people for running a private >bridge, or relay (though the latter with a consumer grade router may >be a bad thing for network health). agreed; don't let relays be behind UPnP! > * I think the new code is safer than the old code, because it doesn't >link against 3rd party libraries with "questionable" code quality, >and is in a memory safe language. YMMV there. it is unquestionably safer. > * I have reservations about deploying it as part of Tor Browser for >use with flashproxy due to poor router side code. Ultimately this >is the support team's call, and if they're ok with it, I will do the >integration work here. > >Most of the really broken (non-security) behavior only happens when >the uPnP table starts to get full, which is presumably not a concern >for the bridge/relay use case (Since like aliens from the planet >Zeist, "There can be only one"). here's the problem: other UPnP speaking devices behind the network will stomp your mapping. it's gonna happen. so not only do you need to consider the support cost of flaky routers and poor behavior of the UPnP gateway, you also need to consider the poor behavior of other UPnP speaking software also trying to do the best thing in a world of shit that is UPee-n-Poop. static port mappings are much better all around, for both support and reliability reasons. > * As far as support/bugfixes/maintenance from my end, there's a limit >to what I can do for quirky/broken routers, and in a lot of cases >this will end up as "patches accepted". i started down a path, trying to match OUI prefix. "This router is probably broken with UPnP, are you sure?" , then checking version from login banners on webUIs, "This firmware may be out of date. You should upgrade first!" , then basically saving UPnP mapping and fuzzing behavior, "do i need to workaround behavior X? what about Y?" . . . that way is madness. just don't... my $0.02 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
On Fri, 24 Jul 2015 16:21:31 + Jacob Appelbaum wrote: [snip] > > 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? I have less objections towards people using tor-fw-helper for bridges than for something like flashproxy or full fledged relays. Full fledged relays because of stuff like: https://tor.stackexchange.com/questions/7164/why-do-relays-not-end-idle-tcp-sessions IMO similar to relays with insufficient bandwidth, relays that can't connect to any other relay on demand as required (due to a full NAT table) do bad things to network health. This is probably an orthogonal discussion though. [snip] > > 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. Unless their router is *extremely* quirky, the new code will work. Pain will start happening if you add lots and lots of mappings depending on how your router behaves when the uPnP table gets full (since I have to request infinite duration leases). NAT-PMP should basically always work. Again, this is more a flashproxy issue (since the mapping ideally only lasts for as long as the Tor Browser session is active) than a relay one, and we'd want to select a random port at runtime. [snip] > 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. Right. The primary concern when I started my rewrite was the libraries are really scary (since we were linking against stuff that is part of the problem on the router end, that make me nervous). If a user is fully informed about the hazards surrounding uPnP then the new code is probably a fine replacement (It even has a few extra goodies that the original doesn't, like dumping the mapping table, and support for removing mappings). > 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. Indeed. The rewrite wasn't exactly easy either. I think I've done a poor job of communicating my position, so I'll try to summarize it. * I think the new code will work for most people for running a private bridge, or relay (though the latter with a consumer grade router may be a bad thing for network health). * I think the new code is safer than the old code, because it doesn't link against 3rd party libraries with "questionable" code quality, and is in a memory safe language. YMMV there. * I still intend to move the new code from github.com to git.tp.o, and am willing to provide things like signed release tags, and tarballs of releases if that will make packaging it easier, but I won't be the one making packages (unless I happen to get bored enough to put it in AUR). (And I think "apt-get upgrade tor tor-fw-helper", is a reasonable thing to ask of end users.) * I have reservations about deploying it as part of Tor Browser for use with flashproxy due to poor router side code. Ultimately this is the support team's call, and if they're ok with it, I will do the integration work here. Most of the really broken (non-security) behavior only happens when the uPnP table starts to get full, which is presumably not a concern for the bridge/relay use case (Since like aliens from the planet Zeist, "There can be only one"). * If this is deployed to users, they should know that historically
Re: [tor-dev] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
On 7/24/15, Yawning Angel wrote: > On Thu, 23 Jul 2015 23:46:26 + > Jacob Appelbaum 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
Re: [tor-dev] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
On 7/23/15, David Stainton 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. > > Obviously NAT has destroyed the Internet by violating the end to end > principal... however I'd like to remind the thread that many many > other "distributed" software systems also run into this very same NAT > issue. It sucks... and not just for Tor project but this has also > prevented many users of say for example Tahoe-LAFS from deploying > storage servers from their home behind a NAT device. > It would be nice if by using Tor, we solved the end-to-end problem two different ways - by offering .onions and by assisting with any possible automated NAT punching. >>> 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. > > If I understand things correctly the uPnP/NAT-PMP is in fact not the > proper way to solve this problem because of the reasons Yawning > mentioned. IPFS (interplanetary filesystem) currently solves this > problem via some complicated protocol with the selection of a > rendezvous server... similar to Tor hidden services. Clearly this is > the correct way to solve the NAT problem. Am I wrong about this? I think that will never work for a relay or a bridge. Reachability for systems like IPFS has different considerations. In that sense, we've already solved it with hidden services. All the best, Jacob ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
