On 7/24/15, Yawning Angel yawning@schwanenlied.me wrote:
On Thu, 23 Jul 2015 23:46:26 +0000 Jacob Appelbaum jacob@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.
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?
[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-call...
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