[tor-dev] Experimenting with private tor setup
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. Its a pretty normal setup (aside from everything running on my development box) and passes traffic as expected. 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 see this message several times in the logs: Apr 21 01:38:56.000 [info] channel_tls_process_netinfo_cell(): Got good NETINFO cell from xxx.18.110.101:5002; OR connection is now open, using protocol version 4. Its ID digest is 41373151BCC461FEFEFCC1BAF6DCEFD89922014C. Our address is apparently xxx.18.110.101. 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? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Draft of proposal Direct Onion Services: Fast-but-not-hidden services
On Mon, Apr 20, 2015 at 03:18:06PM -0400, A. Johnson wrote: I think new users might not appreciate the difference between similarly named terms and then choose the wrong one to their detriment. It seems better that they should later learn of shared technology that's not clear from the naming differences than be surprised by differences in security properties that they incorrectly assume from similar names. (Perhaps more generally, the naming should reflect how users---broadly construed---should think about these things rather than the mental models that are useful as developers.) It is actually for usability that I dislike making unnecessary distinctions. “Onion service” makes it simple to clients: xyz.onion = service accessible only through Tor. This may be the central source of our disagreement and underscores the importance of terminology. I think of onion service as meaning a service that is reachable only inside of Tor not merely accessible only through Tor. Suppose someone has a sensitive file that they don't want the wrong people to obtain or obtain before, e.g., an intended public release. It would be good for them to easily tell whether the server they're trusting with that file is location protected or self-authenticated or If both Tor-required and heretofore hidden services terms are called onion services, then it won't be apparent simply from the address. (Substitute whatever terms you like for Tor-required and heretofore hidden, which I'm hoping are adequately denoted by my usage here.) And, do we require self-authentication a la current hidden services for those that we want to be faster and more convenient if it e.g. would significantly affect performance? My point is that if we assume these are all called 'onion services' we are likely to assume in all kinds of design requirements or trade-offs without first deciding what we want these things to do and whether it thus makes sense to bind them together in this way (or not). This will then be baked into what 'onion' will mean and entitle one to assume, even or especially for the users that cannot articulate this technically. (As an imperfect analogy, think of the semantics of the lock icon or the green highlighting etc. in URL bars.) Put differently, whoever's terminological preferences win, we should get much clearer on these things before we treat this draft as more than a toy to help us work these out. aloha, Paul ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Experimenting with private tor setup
Date: Tue, 21 Apr 2015 02:13:48 -0400 From: CJ Ess zxcvbn4...@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. With the latest versions of tor and chutney, the basic-min configuration bootstraps a testing tor network with 3 authorities (non-exits), 1 exit relay, and 1 client. I'm pretty sure this is the minimum number of tor instances to bootstrap, as bootstrapping requires each relay to create a 3-hop path through other relays which have already bootstrapped (or, in this case, the 3 authorities, which assume their own reachability). I'm not sure if you're using chutney to set up your network. chutney simplifies the setup of local tor networks using a templating and launch system. The latest version can be downloaded using: git clone https://git.torproject.org/chutney.git Its a pretty normal setup (aside from everything running on my development box) and passes traffic as expected. 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 see this message several times in the logs: Apr 21 01:38:56.000 [info] channel_tls_process_netinfo_cell(): Got good NETINFO cell from xxx.18.110.101:5002; OR connection is now open, using protocol version 4. Its ID digest is 41373151BCC461FEFEFCC1BAF6DCEFD89922014C. Our address is apparently xxx.18.110.101. 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). Alternately, you could have discovered a similar bug which occurs when all tor instances in a network are on the same, public IP address. Please feel free to log a bug if this behaviour is still showing up in tor versions after 0.2.6.1 - and reference #13924 so we know the history of the issue. https://trac.torproject.org/projects/tor/newticket You could also disable reachability testing entirely using: AssumeReachable 1 TestingTorNetworks also allow you to skip several boring minutes of bootstrap by just voting everything a guard and an exit (only in recent versions of tor): TestingDirAuthVoteExit * TestingDirAuthVoteHSDir * Let us know how you go. 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onionoo resource requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Improved documentation and process of setting up Onionoo would be welcomed by more people, including myself. Busy setting up Compass and with Atlas and Globe mirrors active the cherry on the pie would be an own Onionoo instance (if needed also as backup for onionoo.torproject.org). At the moment having onionoo running at thecthulhu.com is a nice backup, I do not know if any more of such mirrors are acceptable or preferable. On 21-4-2015 22:16, Karsten Loesing wrote: On 21/04/15 22:06, nusenu wrote: Hi Karsten, Though it's very likely easier to parse those directly (possibly using Stem) rather than setting up an Onionoo instance for the exact time you're interested in. can you say something about what amount of minimal memory and disk space one would probably need for a non-public onionoo instance? I'd say 8G RAM and 100G disk space could work, though 16G RAM and 250G disk would save you some trouble during the initialization phase when you feed tons of descriptors into it. If you want to give this a try, I'd want to take that opportunity and improve the documentation and maybe also the process for setting up Onionoo, if you're interested in helping with that. All the best, Karsten ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev - -- Tim Semeijn Babylon Network pgp 0x5B8A4DDF -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVNrq6AAoJEIZioqpbik3fR2sP/1njsgQulsnY2OkgXRjTWkkv 5t0gp30bPm8Bgwl4CdxO8NWzXyQt/zeWulf59j1ccvtds0EmclMvQ0iqUsP4RMhC tfawZY0tXWf0nm79sQCgQTZ3SG1FJ6SqoWUSVbQ/GRQlAOIA7XK6C1VJA72LXrp5 wTzo4z9Rv9qWGgZjzNrsnvG7iYZbz4muLIDbbwd5brUWC0UfYXlQXA0UbbyFPiBO J6/5iZPsjInwsIscS0tr38g7LxydNFpR24IcodAzPhRcQmMdnjEfuD1I9H/SZhC0 3d+yYo5tIQx33K+g7NrcIm4WWQjye25dgm7W/DsiiJFCKvYgCAppoT46Y3RU2o/p 8ot06zx4TaMhMcNP3GQ/BX61bOB/vTxBeSptXz/NMBbu8UE1UtxYMQn2/shcvLQD SURtx9J+5m9aeXA88jSqm35GzXPhbmvtf5q8OkJD4bSu0vZTb4obhr4LS3JG8C7P TpHNHsZu+Bx473nKCdgVo59h3Q7i2fM53M6TKW/sDgBaFQTGeSjY7pVWNdfMpyBj ZAEA5fnlRVC6HXPIaemuB/zLXptuAlWiKfx4jpmR6h3t8yzx5nUcTc7mGdH6oNfl 2AIMpdca7vZwxMwaO1kW57kqGOHbcG7LiiHxgoRn52mIEWl6YFIpVSf3Xlk3JaoU DzfQN2rLUI/2lNq+kW1R =ZUk9 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onionoo resource requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Karsten, Though it's very likely easier to parse those directly (possibly using Stem) rather than setting up an Onionoo instance for the exact time you're interested in. can you say something about what amount of minimal memory and disk space one would probably need for a non-public onionoo instance? thanks, nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVNq3SAAoJEFv7XvVCELh02xIP/14QAycUAcAhun36WyzhpsC/ gb8Ta0ryCzEBW3zT4//9pyrz3VO08ryLI6Kg/OgrwOSUfVxQtTkhrnYG9GZlr89Z fPW3PgnilPFAikaH4iJzxbvVS8FrZdG3d93QM6uDsMHOfwuZZJg+PXSTfIdAawYc /eS59HfeXDEz/fCQAl+N9YWKJuKQbPqmG3ah9r27ppJRVCp6Upgm1i40s5z2emsC Wg54HBy3n5To04t8mzaW1eJKMlXFXsps6ywxERuVwyfOBPBBL3WViybJLN0IOW59 1k9qJB9UfvaxHVd52+YJw6eNaLBgVOqllz1Dd4tBctNzgUfJKCBKLsmxovQj9Daw GsA+navUOFHHJwXCs9b2yMZa+LcnbYbP3Y2HT0ZwY5al2hy4SsqA7bAyIk7RozEJ 6p8S/Mr7qh7QS0Gw7Dz4AGJ1fVgsR7FBLj2g0XO27SlqhNYC+Mf75eSkF0MQJ6vj YQCJhSZIn4DAs+AG2Ul42aY3/w0LTQfLmjbAfGrvuO1wrupDQ+6D1nvFc9AYVLHR IWhco4XdQiVOLnmDAs8bMY/llFS+3x1Tf7gVKV0rP17w6NTLsgLXq9B2ufkBYwaR nLWOGIQ3AeoBapONFmFe1Klv7/69mu0NiWsQ8Nx1JIc2Ogt+VzRrWC1jyBcbI8hC yXqlQeW9FNizS9b3SZUo =Hn+K -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Experimenting with private tor setup
Chutney sounds really cool, but this is more of a learning exercise so I'll keep at it manually for a bit. I read someplace that test instances on the public tor are near useless, so I tried setting TestingTorNetwork 0 on all he routers and one of the directory servers in case there was some logic guarding against instances with different values. The directory authority came up and did participate in consensus generation but never decided that the orport/dirport was reachable. None of the routers did any better. However they do seem to be successfully creating circuits to other routers and the directory authorities. I turned on debug logging and went through it line for line, and if there are any complaints they are not being logged. It looks like there are only a few bits of code involved in the reachability tests, I'll throw in some printfs and see if I can catch whats happening. That failing I have a good test case I can submit. I'm using Tor v0.2.6.7 for all this BTW. On Tue, Apr 21, 2015 at 9:01 AM, teor teor2...@gmail.com wrote: Date: Tue, 21 Apr 2015 02:13:48 -0400 From: CJ Ess zxcvbn4...@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. With the latest versions of tor and chutney, the basic-min configuration bootstraps a testing tor network with 3 authorities (non-exits), 1 exit relay, and 1 client. I'm pretty sure this is the minimum number of tor instances to bootstrap, as bootstrapping requires each relay to create a 3-hop path through other relays which have already bootstrapped (or, in this case, the 3 authorities, which assume their own reachability). I'm not sure if you're using chutney to set up your network. chutney simplifies the setup of local tor networks using a templating and launch system. The latest version can be downloaded using: git clone https://git.torproject.org/chutney.git Its a pretty normal setup (aside from everything running on my development box) and passes traffic as expected. 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 see this message several times in the logs: Apr 21 01:38:56.000 [info] channel_tls_process_netinfo_cell(): Got good NETINFO cell from xxx.18.110.101:5002; OR connection is now open, using protocol version 4. Its ID digest is 41373151BCC461FEFEFCC1BAF6DCEFD89922014C. Our address is apparently xxx.18.110.101. 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). Alternately, you could have discovered a similar bug which occurs when all tor instances in a network are on the same, public IP address. Please feel free to log a bug if this behaviour is still showing up in tor versions after 0.2.6.1 - and reference #13924 so we know the history of the issue. https://trac.torproject.org/projects/tor/newticket You could also disable reachability testing entirely using: AssumeReachable 1 TestingTorNetworks also allow you to skip several boring minutes of bootstrap by just voting everything a guard and an exit (only in recent versions of tor): TestingDirAuthVoteExit * TestingDirAuthVoteHSDir * Let us know how you go. 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
Re: [tor-dev] onionoo resource requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21/04/15 22:06, nusenu wrote: Hi Karsten, Though it's very likely easier to parse those directly (possibly using Stem) rather than setting up an Onionoo instance for the exact time you're interested in. can you say something about what amount of minimal memory and disk space one would probably need for a non-public onionoo instance? I'd say 8G RAM and 100G disk space could work, though 16G RAM and 250G disk would save you some trouble during the initialization phase when you feed tons of descriptors into it. If you want to give this a try, I'd want to take that opportunity and improve the documentation and maybe also the process for setting up Onionoo, if you're interested in helping with that. All the best, Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVNrAnAAoJEJD5dJfVqbCr9ZgIAL3gWt9AJc0YMD4658dtXaPw hKiHEU7ghZl5nzzKBroamDYw2yb1d8J4sT2IIdmn0uY+2Vg/tAypT5Fw9NImbuuW D63DoHoTxpE4EiNQbBlWK8ftpZQc+sOPJBNS46bDTKPWJyt3w1N0tT0ixC3TuyFO XC3jzcgghrHPD/EwxrxUFMWOY3CS09VlyETIFEtsfqapPBFBZKt+Ige9iEnQyrrc gFEFbrNxiPwxd9u3yHhwyP56cjoilbrd7OXpy9G4Nl8kHA3cJqTFWMvKhOWvgIKz hxlrJP1haTO8mPMklio0/n1DLGqgFIvqsm+zRTxZxDt6kKgSZmwaES7LjYa8y54= =6OkR -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
