[tor-dev] tor-fw-helper redux

[Yawning Angel]

On Sun, 26 Oct 2014 02:07:26 -0700
David Fifield <david at bamsoftware.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20141026/3df01d46/attachment.sig>