Yawning's mail below reminds me: I am considering removing the C implementation of tor-fw-helper from the tor distribution, and recommending Yawning's pure-Go implementation instead. But before I do this, I'd like to get some sense of whether folks are shipping tor-fw-helper today, or using it in practice.
On Jul 21, 2015 11:26 AM, "Yawning Angel" yawning@schwanenlied.me wrote:
On Wed, 22 Jul 2015 01:06:41 +1000 teor teor2345@gmail.com wrote:
On 20 Jul 2015, at 11:11 , Serg std.serg@gmail.com wrote:
How do you plan to map ports on NAT devices?
If it can't be done automatically using UPnP, This must be done manually. No alternative cases.
Our experience is that most routers' UPnP / NAT-PMP implementations don't work well with (our) automated tools. So this would have to be done manually, significantly reducing the pool of available volunteers.
Just chiming in here. This may well work for a good number of users, but the support overhead for when it fails is utterly gigantic because certain brands of consumer routers have extremely poor UPnP/NAT-PMP implementations.
The usual symptom of a poor implementation is "the router crashes" but certain other behaviors have been documented in the past by people trying to use UPnP in ways that are spec compliant such as "the router crashes and requires a NVRAM reset", "random port mappings get obliterated", "the UPnP/NAT-PMP stack on the router crashes" etc.
I wonder how commercial software handles these cruddy routers. Do they restrict themselves to a tiny part of the spec? Do they probe for problematic firmware, and maintain a list of unreliable versions?
[I am very glad it is not our job to maintain such a list.]
On Tue, 21 Jul 2015 11:38:00 -0400 Nick Mathewson nickm@torproject.org wrote:
Yawning's mail below reminds me: I am considering removing the C implementation of tor-fw-helper from the tor distribution, and recommending Yawning's pure-Go implementation instead. But before I do this, I'd like to get some sense of whether folks are shipping tor-fw-helper today, or using it in practice.
On this note, should I move my tor-fw-helper rewrite from github to git.torproject.org? It hasn't had commits for a while, but it's not the kind of code that really rots (and it is complete/portable).
Regards,
On Tue, Jul 21, 2015 at 11:56 AM, Yawning Angel yawning@schwanenlied.me wrote:
On Tue, 21 Jul 2015 11:38:00 -0400 Nick Mathewson nickm@torproject.org wrote:
Yawning's mail below reminds me: I am considering removing the C implementation of tor-fw-helper from the tor distribution, and recommending Yawning's pure-Go implementation instead. But before I do this, I'd like to get some sense of whether folks are shipping tor-fw-helper today, or using it in practice.
On this note, should I move my tor-fw-helper rewrite from github to git.torproject.org? It hasn't had commits for a while, but it's not the kind of code that really rots (and it is complete/portable).
I'm in favor of it. Ping me some time we're online and I'll make you a repository?
On 7/21/15, Nick Mathewson nickm@torproject.org wrote:
Yawning's mail below reminds me: I am considering removing the C implementation of tor-fw-helper from the tor distribution, and recommending Yawning's pure-Go implementation instead. But before I do this, I'd like to get some sense of whether folks are shipping tor-fw-helper today, or using it in practice.
Does the pure-Go implementation support NAT-PMP or just UPnP?
I still use tor-fw-helper when I hand compile Tor on obscure systems. Generally this means a Novena board when I need a newer version of Tor than is already packaged.
Also - does this mean that after many many years... that this new version of tor-fw-helper be enabled by default at build time? Pretty please? :-)
All the best, Jake
On Thu, 23 Jul 2015 16:54:33 +0000 Jacob Appelbaum jacob@appelbaum.net wrote:
On 7/21/15, Nick Mathewson nickm@torproject.org wrote:
Yawning's mail below reminds me: I am considering removing the C implementation of tor-fw-helper from the tor distribution, and recommending Yawning's pure-Go implementation instead. But before I do this, I'd like to get some sense of whether folks are shipping tor-fw-helper today, or using it in practice.
Does the pure-Go implementation support NAT-PMP or just UPnP?
It supports both, though NAT-PMP is limited to Linux, Windows, and *BSD (including Darwin), due to the need to query the routing table to obtain the IP address of the default gateway.
It's easy-ish make the new code's NAT-PMP support other platforms (implement one function), but since the existing support covers what's needed I haven't gone and hunted down more obscure things.
I still use tor-fw-helper when I hand compile Tor on obscure systems. Generally this means a Novena board when I need a newer version of Tor than is already packaged.
Also - does this mean that after many many years... that this new version of tor-fw-helper be enabled by default at build time? Pretty please? :-)
Unlikely, AFAIK the general plan was to have it as a separate package.
Also - does this mean that after many many years... that this new version of tor-fw-helper be enabled by default at build time? Pretty please? :-)
Unlikely, AFAIK the general plan was to have it as a separate package.
That is really a major bummer if so - we should be shipping this code and enabling it by default. If a user wants to run a relay, they should only have to express that intent with a single button.
All the best, Jake
It's probably for the best. The implementation of upnp and nat-pmp is frequently done incorrectly. Many implementations simply break the fw security or leak identifying information by enabling the feature. I once saw a case which opened port 0 everytime upnp was used. Not closed, or stealth, but open. Encouraging running a relay is all good, but doing it and not being able to account for implementations which introduce security problems is risky.
--leeroy
On 7/23/2015 at 2:26 PM, "Jacob Appelbaum" wrote:>> Also - does this mean that after many many years... that this new
version of tor-fw-helper be enabled by default at build time?
Pretty
please? :-)
Unlikely, AFAIK the general plan was to have it as a separate
package.
That is really a major bummer if so - we should be shipping this code and enabling it by default. If a user wants to run a relay, they should only have to express that intent with a single button.
All the best, Jake
On Thu, 23 Jul 2015 18:26:33 +0000 Jacob Appelbaum jacob@appelbaum.net wrote:
Also - does this mean that after many many years... that this new version of tor-fw-helper be enabled by default at build time? Pretty please? :-)
Unlikely, AFAIK the general plan was to have it as a separate package.
That is really a major bummer if so - we should be shipping this code and enabling it by default. If a user wants to run a relay, they should only have to express that intent with a single button.
The problem with this (and why we're not shipping it in Tor Browser, even if it would make flashproxy actually usable/useful to a large number of users) is because there is no one that is willing/able to deal with every single instance of:
* "My router crashed" * "My router crashed and I had to factory reset it" * "Why do I need to open a UDP port on my computer's firewall for uPnP/NAT-PMP to work, and how do I do that?" * "Random unrelated port mappings got blown away" * "My router's NAT TCP session table filled up" * "My ISP is complaining that I'm on some random asshole's blacklist because they include every single Tor Relay" * "Sites that used to work no longer work because some random asshole's blacklist includes every single Tor Relay" * etc, etc, etc, etc
And I certainly can't deal with "my router has a strange idea of what the uPnP spec actually says, and it fails to port forward" (unless they have/know how to use wireshark).
I'm as unhappy at the general situation surrounding the codebase as anyone else, and if I thought deploying it would be a good idea, I'd be strongly pushing for it, since I think the new code I wrote will work for a lot of people.
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.
Regards,
On 7/23/15, Yawning Angel yawning@schwanenlied.me wrote:
On Thu, 23 Jul 2015 18:26:33 +0000 Jacob Appelbaum jacob@appelbaum.net wrote:
Also - does this mean that after many many years... that this new version of tor-fw-helper be enabled by default at build time? Pretty please? :-)
Unlikely, AFAIK the general plan was to have it as a separate package.
That is really a major bummer if so - we should be shipping this code and enabling it by default. If a user wants to run a relay, they should only have to express that intent with a single button.
The problem with this (and why we're not shipping it in Tor Browser, even if it would make flashproxy actually usable/useful to a large number of users) is because there is no one that is willing/able to deal with every single instance of:
- "My router crashed"
- "My router crashed and I had to factory reset it"
- "Why do I need to open a UDP port on my computer's firewall for uPnP/NAT-PMP to work, and how do I do that?"
- "Random unrelated port mappings got blown away"
- "My router's NAT TCP session table filled up"
- "My ISP is complaining that I'm on some random asshole's blacklist because they include every single Tor Relay"
- "Sites that used to work no longer work because some random asshole's blacklist includes every single Tor Relay"
- etc, etc, etc, etc
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.
And I certainly can't deal with "my router has a strange idea of what the uPnP spec actually says, and it fails to port forward" (unless they have/know how to use wireshark).
In that case, we don't get a bridge or a relay, we may get a bug report and we will overall have more bridges or relays with less effort.
I'm as unhappy at the general situation surrounding the codebase as anyone else, and if I thought deploying it would be a good idea, I'd be strongly pushing for it, since I think the new code I wrote will work for a lot of people.
I think that if you have high confidence in the code, I *really* want to deploy it.
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.
I admit, I am pretty frustrated that we implemented it, shipped the code for years and I'm probably the only person who really used it because of what feels like fear, uncertainty and doubt. Some of the concerns makes sense but it mostly just strikes me as a farce at this point. We can always make it harder later but we haven't really tried to make it easier, ever.
Any user that can compile a Go program can probably just do the NAT punching on their own anyway...
All the best, Jacob
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.
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?
On Thu, 23 Jul 2015 12:50:29 -0700 David Stainton dstainton415@gmail.com wrote:
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?
NAT-PMP (aka PCP) is less awful than uPnP is, may actually be ok (as long as you don't try to remove port mappings due to a bug in older miniupnpd), but is primarily an Apple-ism limiting it's usefulness.
OTOH, the far more widely supported/deployed uPnP, on consumer routers at least, should be disabled and treated with extreme suspicion till proven otherwise.
Regards,
On 7/23/15, David Stainton dstainton415@gmail.com 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
On Thu, 23 Jul 2015 19:18:34 +0000 Jacob Appelbaum jacob@appelbaum.net 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.
Do users know that their router's implementation of NAT-PMP/uPnP is shit? It's more a uPnP issue, but I found bugs in at least one NAT-PMP implementation when writing the code (fixed in upstream, don't know how many people are running the newer code).
Utterly horrific behavior especially in uPnP implementations is a well known and well documented problem.
Eg: * http://www.upnp-hacks.org/annoyances.html * https://tools.ietf.org/html/rfc6886 (Sec. 9.5) * https://community.rapid7.com/servlet/JiveServlet/download/2150-1-16596/Secur...
While the situation has probably improved over the years, having users use a feature on their router that should be off until the router firmware is known not to be horrible (See the report on RCE vulnerabilities) doesn't feel great to me. How many average users keep their router firmware up to date?
[snippity]
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.
I briefly spoke to Lunar about this at Valencia when I was asked why, given a rewrite exists that it's not being shipped with flashproxy. I was less focused on the relay side of things and more on flashproxy specific issues, which I'm still convinced will be Not Fun to support.
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.
I admit, I am pretty frustrated that we implemented it, shipped the code for years and I'm probably the only person who really used it because of what feels like fear, uncertainty and doubt. Some of the concerns makes sense but it mostly just strikes me as a farce at this point. We can always make it harder later but we haven't really tried to make it easier, ever.
Part of this sounds like a documentation issue.
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
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.
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.
Regards,
On 7/23/15, Yawning Angel yawning@schwanenlied.me wrote:
On Thu, 23 Jul 2015 19:18:34 +0000 Jacob Appelbaum jacob@appelbaum.net 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.
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?
It's more a uPnP issue, but I found bugs in at least one NAT-PMP implementation when writing the code (fixed in upstream, don't know how many people are running the newer code).
Lots of NAT punching server side code is buggy for sure - I don't think we disagree.
Utterly horrific behavior especially in uPnP implementations is a well known and well documented problem.
Eg:
https://community.rapid7.com/servlet/JiveServlet/download/2150-1-16596/Secur...
I again, agree that this is all problematic.
While the situation has probably improved over the years, having users use a feature on their router that should be off until the router firmware is known not to be horrible (See the report on RCE vulnerabilities) doesn't feel great to me. How many average users keep their router firmware up to date?
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?
[snippity]
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.
I briefly spoke to Lunar about this at Valencia when I was asked why, given a rewrite exists that it's not being shipped with flashproxy. I was less focused on the relay side of things and more on flashproxy specific issues, which I'm still convinced will be Not Fun to support.
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.
I admit, I am pretty frustrated that we implemented it, shipped the code for years and I'm probably the only person who really used it because of what feels like fear, uncertainty and doubt. Some of the concerns makes sense but it mostly just strikes me as a farce at this point. We can always make it harder later but we haven't really tried to make it easier, ever.
Part of this sounds like a documentation issue.
I don't agree - the history is that everyone hated the libraries that were used and Tor is (correctly) an extremely conservative culture when it comes to software design. Sadly, attempts to fork and include the needed code were totally shot down - so it meant that it was a rarely used compile time option used by approximately, I'd guess, me.
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.
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.
All the best, Jacob
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.
[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-call...
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,
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
On Fri, 24 Jul 2015 16:21:31 +0000 Jacob Appelbaum jacob@appelbaum.net 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-...
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 a lot of routers have had hilariously broken/insecure uPnP implementations (Documentation issue).
* 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 hope this clarifies things.
Regards,
On 7/24/15, Yawning Angel yawning@schwanenlied.me 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
On 7/24/15, Yawning Angel yawning@schwanenlied.me wrote:
On Fri, 24 Jul 2015 16:21:31 +0000 Jacob Appelbaum jacob@appelbaum.net 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.
I think in all cases - a person should signal intent and we should automate things. A relay once required contacting Roger by hand - eventually it self-tested and now it is mostly automatic with one small stumbling block.
Full fledged relays because of stuff like: https://tor.stackexchange.com/questions/7164/why-do-relays-not-end-idle-tcp-...
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.
I think it is orthogonal - we should be so lucky as to have too many relays that are awful in the network. That is not the core problem, I think. The core problem is that when someone wants to help, we don't make it frictionless - we load them with guilt about learning weird and sometimes obtuse stuff that is in my view unnecessary.
[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.
That is good to hear - I agree that some routers will probably not work. I think it would be great to get some numbers and other data on those failure modes.
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.
Ok. I understand.
[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).
To be clear - I think the library code is awful too. This is partially why I suggested we fork it and ship a fork. This is what the Vidalia GUI did - they just didn't do the NAT-PMP part of the task. Ironically, I think nearly no one every complained about that breaking their routers or anything horrible. I wonder if anyone uses that code anymore?
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'd like to say that I think informed consent here is good but also a strange thing. It feels like we should remember that Free Software comes with no warranty. That means that it may melt their home router or scare their cat. Hopefully it merely maps a port. :-)
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 I grok you now - the key thing I missed was the worry about flash proxies.
- 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).
Ok.
- 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 think you are right - I'd even advocate for a bit of go-seccomp - thus ensuring that the code is reasonably sandboxed. Along some MAC of some kind like AppArmor or SELinux or seatbelt, I can't imagine that you aren't perfect by comparison to the other library code.
- 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).
That sounds fine by me - I think that if that other stuff is done - it is easy to package it.
(And I think "apt-get upgrade tor tor-fw-helper", is a reasonable thing to ask of end users.)
I agree - we can easily package it for Debian - it could and should also be part of the other bundles we ship, I think. I guess I can package it for Debian - I'd like to take a look though before I commit.
- 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.
OK. Sounds reasonable.
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").
Ha. Understood.
- If this is deployed to users, they should know that historically a lot of routers have had hilariously broken/insecure uPnP implementations (Documentation issue).
Agreed.
- 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".
Seems reasonable.
I hope this clarifies things.
Completely. Thank you.
All the best, Jake
Just to touch base on this, and to give a rough status of where things are.
The tor codebase no longer includes the C tor-fw-helper as of:
d2cb92332009567ae778b3570e8fd3420c207446
Closes https://trac.torproject.org/projects/tor/ticket/13338
The new (Go based code) now lives at:
https://gitweb.torproject.org/tor-fw-helper.git/
I changed the import paths and what not so that:
$ go get git.torproject.org/tor-fw-helper.git/tor-fw-helper $ $GOPATH/bin/tor-fw-helper
Does the right thing, at least on my box. In theory as long as the toolchain is properly setup, this will work on Linux, *BSD, OSX, and Windows, though it has been a while since I tested non-Linux (no major functional changes were made so I expect it to still work).
If people don't like Go for some reason, they can write a functional replacement in $languageOfChoice, though unless they use library code, it is Not Very Fun.
On Tue, 28 Jul 2015 01:18:07 +0000 Jacob Appelbaum jacob@appelbaum.net wrote:
- 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).
That sounds fine by me - I think that if that other stuff is done - it is easy to package it.
I don't quite have time to do the man page at the moment, but once that is done, I'll tag, and put signed tarballs up somewhere sensible. Since there are no dependencies required beyond a new-ish Go compiler, this should be utterly trivial to package.
I'll try to do this sooner rather than later, but no promises since IRL stuff is on fire for the remainder of the week.
Regards,
On Tue, Jul 21, 2015 at 11:38:00AM -0400, Nick Mathewson wrote:
Yawning's mail below reminds me: I am considering removing the C implementation of tor-fw-helper from the tor distribution, and recommending Yawning's pure-Go implementation instead. But before I do this, I'd like to get some sense of whether folks are shipping tor-fw-helper today, or using it in practice.
pure-Go implementation does not compiled on many archs. Because Go's "gc" compiler supports only i386, amd64, ARM and IBM POWER processor architectures (from Wikipedia) and gccgo, GCC frontend (GCC >= 4.6), does not work everywhere too because of old architecture or architecture's resctriction.
C implementation working everywhere.
So, what is the purpose?
-
coderman -
David Stainton -
Jacob Appelbaum -
l.m -
Nick Mathewson -
Nick Mathewson -
Yawning Angel -
Артур Истомин