On Sun, Oct 26, 2014 at 08:41:08AM +0000, Yawning Angel wrote:
Hello,
"You are in a maze of twisty little firmwares, all terrible".
I'm at the point where the new and improved firewall helper could use some additional testing by various users, though there's some issues with the design that still need to be resolved. But not being one to keep issues inherited from the original from stopping progress...
Code: https://github.com/yawning/go-fw-helper Bug: https://trac.torproject.org/projects/tor/ticket/13338
This is great. Is there any reason not to call it tor-fw-helper, and replace/deprecate the existing src/tools/tor-fw-helper?
I'm thinking that as a conservative step, we should first deploy using a static external port for flash proxy. An ephemeral port is better for scanning resistance, but there is also the risk of poking long-lasting holes in firewalls and overflowing port forwarding tables in these shoddy routers.
We need at least to add a loop to where flashproxy-client calls the port forwarding helper. Ideally we would also try to remove the mapping before exiting. We could do it in the first SIGINT handler--though we know that SIGINT handling doesn't work on Windows because tor immediately zaps you with TerminateProcess. We could do something like we do with terminateprocess-buffer and meek-client-torbrowser, and add an --exit-on-stdin-eof option to flashproxy-client so that it can detect when it is supposed to shut down gracefully. I'm not sure it's worth it though, especially if unmapping ports is unreliable.
We'll need a tor-browser-bundle branch that builds go-fw-helper and adds it to the ClientTransportPlugin line. I'll look at adding the flashproxy-client loop.
- The UPnP mapping description is hard coded to "Tor relay" to match tor-fw-helper.
Is there any way to omit it or leave it blank? I thought there was a ticket somewhere about "Tor relay" making Tor use more conspicuous, but I can't find it now.
David Fifield