On Tue, Mar 18, 2014 at 10:59:30PM -0400, James Valleroy wrote:
> The FreedomBox project [1] is planning to include Tor in the upcoming
> 0.2 release. FreedomBox is intended to be used as an always-on server,
> so its Tor node has been configured as a bridge relay.
>> There is also a need for FreedomBoxes to be able to find each other
> regardless of location or restrictive firewall. This feature is not
> yet completely implemented for FreedomBox, but it will likely involve
> each box running a Tor hidden service, and making the initial
> connection to other boxes over the Tor network.
Running as a bridge and a hidden service at the same time is likely fine,
but you should read through
https://blog.torproject.org/blog/protecting-bridge-operators-probing-attacks
to be aware of some potential issues there.
In short, running the bridge could make it easier for somebody
to guess-and-check whether that hidden service address is
associated with that bridge. So if the hidden service is primarily a
reachability-despite-NATs thing, rather than a "you'll never find out
where I am" thing, sounds great.
> Here is the configuration that we are currently using in /etc/tor/torrc:
>> ORPort 4431
> BridgeRelay 1
> Exitpolicy reject *:*
Are these things going to be on the network directly, i.e. without
requiring manual port forwarding by the operator? If so, you might
explore whether you prefer "ORPort auto" for more variety.
Also, if these things are going to *be* the network connection (I've
lost track of what all freedombox might be), you might also look at the
contributed traffic priority script:
https://gitweb.torproject.org/tor.git/blob/HEAD:/contrib/linux-tor-prio.sh
but a) if it's just a bridge, it's probably not so big a deal in terms
of competing with the user's traffic, and b) it looks like that script
really wants you to tell it about the network's speed, which will be
hard for you to guess. So nice idea in theory, but probably not worthwhile
in practice.
--Roger