On Sun, 26 Oct 2014 02:07:26 -0700 David Fifield <david@xxxxxxxxxxxxxxx> wrote: > 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? No particular reason for the former. This could even be done at the packaging step since I kind of don't want to move the repo. I think, assuming people like my stab at this, that having it live in it's own space under git.tp.o somewhere would be best. > 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. Indeed. It has no external dependencies so adding it to the build process should be trivial, just not something I've bothered with yet. > 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. I would think it's worth trying to do so, particularly if ephemeral ports are used. NAT-PMP mappings (the one that has routers that have trouble unmapping), have a sane lifespan (currently 2h, but changing this is trivial). As far as I know removing UPnP mappings should always work, and that's the protocol that needs infinite duration mappings due to firmware badness. There's no harm in trying to unregister mappings. Unless the undocumented flag is set, go-fw-helper will just fail to remove NAT-PMP mappings with an internal error. I changed the reporting for the deregistration process to mostly match the registration as well, so automating this is straight forward. I may reconsider disallowing NAT-PMP deregistration since the router side implementation where I found the bug supports both UPnP and NAT-PMP, and so in such environments UPnP should be used anyway due to how the code is setup. > 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. It's a constant in the UPnP code. This is also trivial to omit/change, if people want it to be different, but having it well defined makes the admin side of things easier. NAT-PMP doesn't have a description field. As a side note, before I sent the e-mail, I was browsing the web for a bit with flashproxy configured to use the helper, so at least in my test environment things work as expected. -- Yawning Angel
Attachment:
pgp0uZa5AJ_0E.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev