Date: Wed, 22 Apr 2015 01:05:44 -0400 From: CJ Ess zxcvbn4038@gmail.com
On Tue, Apr 21, 2015 at 9:01 AM, teor teor2345@gmail.com wrote:
Date: Tue, 21 Apr 2015 02:13:48 -0400 From: CJ Ess zxcvbn4038@gmail.com
I've been experimenting with a private tor setup - I've managed to setup a couple directory authorities, six routers/exit nodes (which seemed to be the minimum to bootstrap everything), and a client.
…
So I'm wondering what would happen if I set TestingTorNetwork to 0, so I picked one onion router instance and made that change.
Because its all running on one box I had to keep some of the special settings: DirAllowPrivateAddresses 1 EnforceDistinctSubnets 0 AuthDirMaxServersPerAddr 0 AuthDirMaxServersPerAuthAddr 0 ExtendAllowPrivateAddresses 1
And that almost works, I got this far:
Apr 21 00:50:09.000 [notice] Bootstrapped 100%: Done Apr 21 00:50:09.000 [notice] Now checking whether ORPort xxx.18.110.101:5106 is reachable… (this may take up to 20 minutes -- look for log messages indicating success) Apr 21 01:10:09.000 [warn] Your server (xxx.18.110.101:5106) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Apr 21 01:30:09.000 [warn] Your server (xxx.18.110.101:5106) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
It looks like the "is reachable" is determined by opening a circuit.
…
I don't see any warnings or errors, it looks like the circuits are being opened successfully. Any ideas why this doesn't translate to getting past the ORPort being reachable test?
If you're using a version of tor before 0.2.6.1, then it's possible that bug #13924 may be the culprit: https://trac.torproject.org/projects/tor/ticket/13924 "Reachability testing and channel is_local assume private addresses are local" (and therefore discount the local/private addresses for the purposes of reachability testing).
…
I found the problem here: https://github.com/torproject/tor/blob/cc10f13408e25eaf04f849d0f761680f383fa...
The check for channel_is_local returns true because my dev box has an 172.16/12 address:
https://github.com/torproject/tor/blob/725d6157df150ec9151450dc2422d9838c201...
And thats what is keeping everything from working.
The 172.16/12 block is a private address block. https://en.wikipedia.org/wiki/Private_network
tor assumes that connections from private addresses are local. It doesn't update its reachability self-testing flag unless it gets a connection from a non-local address.
This restriction is relaxed when TestingTorNetwork is set, as many test networks use private address blocks.
I commented out that address block and now orport, dirport, and bandwidth tests are running.
Commenting out a private address range is a dangerous change that has at least the following security implications: * "ExitPolicyRejectPrivate 1" won't stop clients exiting to the block you've commented out (warning, you have this set to the default, 1) * "ExtendAllowPrivateAddresses 0" won't stop clients extending to the block you've commented out (but you have this set to 1) * "DirAllowPrivateAddresses 0" won't exclude directory nodes with IPs in the block you've commented out (but you have this set to 1)
As long as you trust your entire network, including any clients that can connect to any open ports, this should not be a problem. But please don't use versions of tor with this change on the public Tor network, you'd be opening yourself up to attack.
It appears that my original fix to bug #13924 didn't anticipate anyone using "ExtendAllowPrivateAddresses 1" without "TestingTorNetwork 1". I'll submit a patch which swaps TestingTorNetwork for ExtendAllowPrivateAddresses. This will preserve the existing fix, because "TestingTorNetwork 1" implies "ExtendAllowPrivateAddresses 1".
The relevant line is here:
https://github.com/torproject/tor/blob/cc10f13408e25eaf04f849d0f761680f383fa...
In the interim, if you'd like a safer option, you could make the same code change to that line, or disable reachability testing entirely using "AssumeReachable 1".
teor
teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
On 22 Apr 2015, at 23:24 , teor teor2345@gmail.com wrote: …
It appears that my original fix to bug #13924 didn't anticipate anyone using "ExtendAllowPrivateAddresses 1" without "TestingTorNetwork 1". I'll submit a patch which swaps TestingTorNetwork for ExtendAllowPrivateAddresses. This will preserve the existing fix, because "TestingTorNetwork 1" implies "ExtendAllowPrivateAddresses 1".
The relevant line is here:
https://github.com/torproject/tor/blob/cc10f13408e25eaf04f849d0f761680f383fa...
…
CJ,
I have made this change and it's waiting for review in the Tor Project Trac system.
Please see: https://trac.torproject.org/projects/tor/ticket/15771
Or on github: Branch: bug-15771-reachability Repository: https://github.com/teor2345/tor.git
teor
teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
No worry, I won't try to use these settings on anything connected to the public tor network. I will try out your fix - I'm working with v0.2.7.0-alpha-dev from the git repository now.
In the mean time it looks like I've been successful in bootstrapping a private network without the testing flag, despite everything being on one server (with only a 172.16/12 interface). The directory authorities are voting, the routers are passing the reachability and bandwidth tests, and I can start a client and make requests through it.
I think that just leaves a couple questions for now:
- I know the directory authority's certificate needs to be renewed periodically (looks like 12 months default). Since it asked for a password that is something I need to do manually then send a HUP, correct? Later on I'll try to hack generating a cert with days or hours of time just to see what happens, but would like to know what the correct way to handle it is.
- All of my routers have done the bandwidth tests, but I see this warning on the DAs with each vote:
Apr 22 22:39:41.000 [warn] Consensus with empty bandwidth: G=0 M=5 E=0 D=243 T=248
Is this something that will fill out as the uptime of the instances increase? Or is this something I should look into?
On Wed, Apr 22, 2015 at 11:05 AM, teor teor2345@gmail.com wrote:
On 22 Apr 2015, at 23:24 , teor teor2345@gmail.com wrote: …
It appears that my original fix to bug #13924 didn't anticipate anyone
using "ExtendAllowPrivateAddresses 1" without "TestingTorNetwork 1". I'll submit a patch which swaps TestingTorNetwork for ExtendAllowPrivateAddresses. This will preserve the existing fix, because "TestingTorNetwork 1" implies "ExtendAllowPrivateAddresses 1".
The relevant line is here:
https://github.com/torproject/tor/blob/cc10f13408e25eaf04f849d0f761680f383fa... …
CJ,
I have made this change and it's waiting for review in the Tor Project Trac system.
Please see: https://trac.torproject.org/projects/tor/ticket/15771
Or on github: Branch: bug-15771-reachability Repository: https://github.com/teor2345/tor.git
teor
teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 23 Apr 2015, at 01:05 , teor teor2345@gmail.com wrote:
On 22 Apr 2015, at 23:24 , teor teor2345@gmail.com wrote: …
It appears that my original fix to bug #13924 didn't anticipate anyone using "ExtendAllowPrivateAddresses 1" without "TestingTorNetwork 1". I'll submit a patch which swaps TestingTorNetwork for ExtendAllowPrivateAddresses. This will preserve the existing fix, because "TestingTorNetwork 1" implies "ExtendAllowPrivateAddresses 1".
The relevant line is here:
https://github.com/torproject/tor/blob/cc10f13408e25eaf04f849d0f761680f383fa...
…
CJ,
I have made this change and it's waiting for review in the Tor Project Trac system.
Please see: https://trac.torproject.org/projects/tor/ticket/15771
Or on github: Branch: bug-15771-reachability Repository: https://github.com/teor2345/tor.git
CJ,
I spoke with Nick about this issue at the dev meeting on IRC yesterday, and he just merged the patch for #15771 into tor's git repository. (Credit to Nick, this is an excellent turnaround time.)
Done!
teor
teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5
teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
-
CJ Ess -
teor