Relay configuration for FreedomBox
Hello, 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. Here is the configuration that we are currently using in /etc/tor/torrc: ORPort 4431 BridgeRelay 1 Exitpolicy reject *:* It is based on example configuration for bridge relays given in the Tor documentation [2] but modified to still allow SOCKS connections. Do you see any vulnerabilities, attacks, or risks with the current configuration, and are there any changes that you would recommend? [1] https://wiki.debian.org/FreedomBox [2] https://www.torproject.org/docs/bridges#RunningABridge Thanks
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 18/03/2014 7:59 PM, James Valleroy wrote:
Do you see any vulnerabilities, attacks, or risks with the current configuration, and are there any changes that you would recommend?
[1] https://wiki.debian.org/FreedomBox [2] https://www.torproject.org/docs/bridges#RunningABridge
If you're going to be running these as bridges, it seems to make sense to include obfsproxy support, probably with obfs3 and scramblesuit [0] enabled right off the bat. Note that scramblesuit requires tor 0.2.5.1 or higher [1], and obfsproxy should be at 0.2.7 or higher [3]. Lines to add to the torrc: 1. ServerTransportPlugin obfs3,scramblesuit exec /usr/bin/obfsproxy managed ([0]) 2. ServerTransportListenAddr obfs3 0.0.0.0:<port number> (if you want to preset your obfs3 port, will be random otherwise) ([3]) 3. ServerTransportListenAddr scramblesuit 0.0.0.0:<port number> (if you want to preset your scramblesuit port, will be random otherwise) ([3]) 4. ExtORPort auto (used internally between tor and obfsproxy, does not need to be forwarded externally, so auto should be fine) ([4]) If I'm giving bad advice, somebody please speak up to correct me! -Lance [0] https://lists.torproject.org/pipermail/tor-relays/2014-February/003886.html [1] https://lists.torproject.org/pipermail/tor-relays/2014-February/003898.html [2] https://lists.torproject.org/pipermail/tor-relays/2014-March/004074.html [3] https://www.torproject.org/projects/obfsproxy-debian-instructions.html.en [4] https://lists.torproject.org/pipermail/tor-relays/2014-February/003962.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBCgAGBQJTKZrEAAoJEECmBqfoBgXnK+cP/RDhzkPBw33vW+VE1ro2QdPo DX6WOB8tiGhMdmOq0oakAqZj8x7nDXs5lO7EcYYzQ7Gnh+ghJVQVBwMzJwX614x9 Hmbk19gvUyf9+9Y9b3gEFQlab1pk3+T0gkOJXu6+6+qHIunoINwa4KrhAYM/h2Ll LzC+IL8IagO9GMGOMeSbqWyHmxHTaOWcZMGuAVZaQ7f07gY7sF/yxjCOuVuzseki QqWQl2gwrvIhyVa7ukEpx/iwY6/+5BokPHDwAzG0oSZwlQCfyvpcIVrPFSO6B6DG +jt4QGAsRKynNg5AaopHKi1F6SJ5ehWuvMOzPjWV8eDgqFimwHgSnRO0k2abwvat ufXcJjtxyvi3j4O3jmTh14768th7QiGB5lLfeg/b8owp+Bnx4hAK9+iQe8L/zWWD 1afQDUC2PHjvyUif0eJ4+rvaPSFxUrb0HNJPE5seVTMPOWtX+P0a2bwJU0Me/7aZ nqgCi7V0aqWjk/AegbkAwdLSHVHK8ChrJBlDsmYviwC8Psmhpkw2sCcJT2ki7mWS xuRqIyU0xugeYhUJSOOUYnmH5iyjsaj6CXEoLG7Jvtke5iSvENlhNeMOjoy4Ppu4 ziKMxozpS1dVprS8Qsbo8TOmrJN2LdcpSVQuXzYeTU0AKEqLSB4rOAws9Ny1t2PZ r/ww4J/SVK9+fgINSgOr =5c2j -----END PGP SIGNATURE-----
On Wed, Mar 19, 2014 at 9:25 AM, Lance Hathaway <qhltx@yahoo.com> wrote:
If you're going to be running these as bridges, it seems to make sense to include obfsproxy support, probably with obfs3 and scramblesuit [0] enabled right off the bat.
Thanks for the information. Is it likely that obfs3 and scramblesuit will be usable in the long-term? Or will they need to be deprecated at some point like obfs2? Also, if obfs3 or scramblesuit were deprecated, but some FreedomBoxes continued to run those transports, what would be the result? Would the worst case be that the bridge is no longer usable by some, as in [0]? The reason that I'm asking is that FreedomBox is currently working within Debian "testing" but our target is Debian "stable". Once our packaged configuration is frozen for the next stable release, it will be more difficult for us to push changes other than security fixes. [0] https://trac.torproject.org/projects/tor/ticket/10314
James Valleroy:
The reason that I'm asking is that FreedomBox is currently working within Debian "testing" but our target is Debian "stable". Once our packaged configuration is frozen for the next stable release, it will be more difficult for us to push changes other than security fixes.
(Debian hat on:) I try to keep Debian backports as up-to-date as possible. Are official backports out of your set of allowed packages as well? -- Lunar <lunar@torproject.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 22/03/2014 11:56 AM, James Valleroy wrote:
Thanks for the information. Is it likely that obfs3 and scramblesuit will be usable in the long-term? Or will they need to be deprecated at some point like obfs2?
Also, if obfs3 or scramblesuit were deprecated, but some FreedomBoxes continued to run those transports, what would be the result? Would the worst case be that the bridge is no longer usable by some, as in [0]?
The reason that I'm asking is that FreedomBox is currently working within Debian "testing" but our target is Debian "stable". Once our packaged configuration is frozen for the next stable release, it will be more difficult for us to push changes other than security fixes.
I can't speak to whether more pluggable transports will be deprecated in future, but I'll go out on a limb here and say "probably." The nature of things ensures that the capabilities of censors continue to advance. And as they do, new approaches will be found and deployed to bypass those advancing attempts to block the network. When bridges were first deployed, the fact that they weren't all openly listed in a public directory made them more difficult to block. Now, most plain bridges are very easy to block. When obfs2 was first deployed, it was a solid protocol (I have no doubt). These days, China is actively hunting down and blocking obfs2. There is very little point to deploying either a plain bridge or an obfs2 pluggable transport these days, especially on a mass scale. On the plus side, obfs3 is still pretty strong, and it's one of the common pluggable transports right now. Scramblesuit is not live in the official bundles yet (AFAIK), but it just released and has some pretty robust-looking defenses against active probing and other attacks. If you're working on something new to deploy, these should be included, without a doubt. They may indeed be deprecated in future, and in the worst case may become unusable or make the bridge more susceptible to being blocked. But if you go with a plain bridge or obfs2, you're already in your worst-case scenario. You have nothing to lose and everything to gain by enabling the newest pluggable transports. I would highly recommend adding the Tor package repository to the FreedomBoxes. As explained in [0], this won't always give you the latest version of tor, but it will provide security fixes. My hunch is that it will almost always also be a little fresher than Debian stable. And given that network censors and network developers are always going to be in an escalating arms race, enabling new releases of Tor (and obfsproxy) directly from the project is going to make the FreedomBox much more useful in the long term. -Lance [0] https://www.torproject.org/docs/debian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBCgAGBQJTLeycAAoJEECmBqfoBgXnJkgP/2//1UQt8syESruHCNoxVPmo 7USRn42O8jcHRCIk3tFLwey+RisG3+E5NQIKDpnvtkX4FevmjAfyje3K+DkI8Nnh QdALbtgfmzFisoCF5DS+XW0pagfhxzI5XcJPq+xOPXBbcGCC7AFqGbK5HdFBNcj1 ZONkMhzQtHLlkdLkEKHT6COpjs64VrbQr3+og04Pntk4LPwmKGbfc8sJoBatsGS4 ojaTYM4DygPo/5UgfbnyhlpF/gt6ymr3EjLy9K+b7ieV8xat5MuMp24GP/pQ+SzX yiN4O2mlFP8W7JfsbIsKDp8f/vIFb60p8O2+FERyfVkot+EGwDN+TLX5cs/KKH7X kclgeUwPhM3A2d8FErWJJJoVeMBbt+cjKqLxnWQowxqnkWAvvFExx73cVYJYBS7r ePKlXl/s/1VMr+uL/i7J+b507WVQRMvi28qspwtoyQWvhIiA5o1EgliU6wPra/Rx FATTkEbMOBv3Xd0jRDUAgvZDxS+cRtcAklfvhdiOJrMXQiYYjomqhT2CLvz6haYI 7+4aKDTlyGfk8LXONqXQugg5Bge8FtI04AeYNXKi/rffUBFRyKJgsWYJG8Hkoemh aWPMiVy9gED5vxmojDGFzYAWIx1ANf5JP8/vKhIh/OkkFauRFaW/OcKA6OJKd4D/ sA7VglzvQuU747MrVmoM =2x1k -----END PGP SIGNATURE-----
On Sat, Mar 22, 2014 at 01:03:43PM -0700, Lance Hathaway wrote:
On the plus side, obfs3 is still pretty strong, and it's one of the common pluggable transports right now. Scramblesuit is not live in the official bundles yet (AFAIK), but it just released and has some pretty robust-looking defenses against active probing and other attacks. If you're working on something new to deploy, these should be included, without a doubt. They may indeed be deprecated in future, and in the worst case may become unusable or make the bridge more susceptible to being blocked. But if you go with a plain bridge or obfs2, you're already in your worst-case scenario. You have nothing to lose and everything to gain by enabling the newest pluggable transports.
Agreed. If the goal in setting it up as a bridge is to be useful to users who are otherwise censored from the Tor network, then running pluggable transports like obfs3 and ScrambleSuit will go a long way towards actually doing that. For context, currently Tor works out-of-the-box (you don't even need a bridge) in nearly all countries except China, where vanilla bridges and obfs2 don't work currently: https://blog.torproject.org/blog/how-to-read-our-china-usage-graphs Periodically Iran and Syria block SSL by DPI, which also takes out vanilla bridges. If you want to be conservative, pick obfs3 and wait for ScrambleSuit to get more mature.
I would highly recommend adding the Tor package repository to the FreedomBoxes. As explained in [0], this won't always give you the latest version of tor, but it will provide security fixes. My hunch is that it will almost always also be a little fresher than Debian stable.
Yes -- I would consider doing this as much for security as for anything else. Debian stable can lag pretty far behind the actual Tor stable releases (depending on which year you're looking). --Roger
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
participants (4)
-
James Valleroy -
Lance Hathaway -
Lunar -
Roger Dingledine