[tor-dev] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)

Jacob Appelbaum jacob at appelbaum.net
Fri Jul 24 16:01:30 UTC 2015


On 7/23/15, David Stainton <dstainton415 at 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


More information about the tor-dev mailing list