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