tor-dev January 2015

tor-dev@lists.torproject.org

58 participants
59 discussions

Re: [tor-dev] how to simulate TOR network through chutney?
by teor 11 Jan '15

11 Jan '15

> Date: Sun, 11 Jan 2015 14:09:56 +0100 > From: Mohiuddin Ebna Kawsar <mohiuddin.kawsar(a)gmail.com> > > Hi teor, > > Thanks for quick reply. i just download new chutney from github and able to > run chutney for nodes = a(3) + r(1) + c(1) but when i set nodes = a(3) + > c(1) i got following message > ############################################################## > ./chutney start networks/basic-min > Starting nodes > <type 'exceptions.IOError'> > Python 2.7.8: /usr/bin/python2 > Sun Jan 11 14:00:27 2015 > <snip> > > /home/raboon/chutney-master/lib/chutney/TorNet.py in > waitOnLaunch(self=<__main__.LocalNodeController object>) > 636 # RunAsDaemon default is 0 > 637 runAsDaemon = False > 638 with open(self._getTorrcFname(), 'r') as f: > 639 for line in f.readlines(): > 640 stline = line.strip() > builtinopen = <built-in function open> > self = <__main__.LocalNodeController object> > self._getTorrcFname = <bound method LocalNodeController._getTorrcFname of > <__main__.LocalNodeController object>> > f undefined > <type 'exceptions.IOError'>: [Errno 2] No such file or directory: > '/home/raboon/chutney-master/net/nodes/003c/torrc' <snip> Hi kawsar, chutney is complaining that you have 4 nodes in your new network, not 5 as it was expecting. Every time you change the torrc_templates or network files, you must run: chutney configure and perhaps some other commands. You may find it easiest to use: tor/src/test/test-network.sh or chutney/tools/bootstrap-network.sh to do this for you. In particular, tor/src/test/test-network.sh will bootstrap and verify the entire network for you, and let you choose: a network --flavour (e.g. basic-min) a --delay before verifying the network (default 18 seconds in 0.2.6.2-alpha) It will also let you configure chutney and tor paths, or you can: set the CHUTNEY_PATH environmental variable to the chutney directory use the default tor/src/or/tor in the build directory, or set the TOR_DIR environmental variable. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED

1 0

Re: [tor-dev] how to simulate TOR network through chutney?
by teor 11 Jan '15

11 Jan '15

> Date: Sun, 11 Jan 2015 12:29:34 +0100 > From: Mohiuddin Ebna Kawsar <mohiuddin.kawsar(a)gmail.com> > > Thank's for your answer with good explanation. yes it worked for > (Authority.getN(3) + Relay.getN(1) + Client.getN(1) ) . For this i have > installed tor-0.2.6.2-alpha-dev and download newest chutney where exit-v4.i > or exit-v6.i don't exist . These files exist in the latest version. Several bugs that make tor network bootstrap fail or slow have been fixed recently. (And others are being fixed soon.) Please get the newest chutney from git and keep it up to date. > now i can see thorough wire-shark that which server i'm queering. > But i got "Couldn't launch test003c (tor --quiet -f > chutney/net/nodes/003c/torrc): 255" when i use (Authority.getN(3) + > Client.getN(1) ) as you mentioned. Your client torrc is broken - this should not happen if you only edited the authority.tmpl file. How did you change the common.i or client.tmpl files? Run the command in the error message without the "--quiet" flag to find out why tor is failing. > and is it also possible to find which authority is acting exit-node? Each authority/relay can act as an exit, and the client may use different exits for different connections. You can use arm to access the client's control port and it should tell you the path(s) it is using. Or you can set up debug logging on the client and it should tell you the path as well. However, wireshark will never tell you, because that's the whole point of Tor: you can only ever see the connections, not how the packets are being relayed. There is documentation on arm in its manual page, and tor logging in its manual page. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED

2 2

how to simulate TOR network through chutney?
by teor 11 Jan '15

11 Jan '15

> Date: Tue, 6 Jan 2015 20:13:51 +0100 > From: Mohiuddin Ebna Kawsar <mohiuddin.kawsar(a)gmail.com> > To: tor-dev(a)lists.torproject.org, matthias.wuebbeling(a)cs.uni-bonn.de > Subject: [tor-dev] how to simulate TOR network through chutney? > > HI, > > I need to simulate TOR network in minimal case [1 ENTRY,1 RELAY,1 EXIT] > node. > how can i do that use chutney? how to setup exit node on my localhost and > how to make circuit with that exit node? > > following are my config file with generated (slightly modified) torc files Hi Mohiuddin, -- Minimum number of instances in a Tor network -- Using 3 tor instances (that is, 2 authorities/relays/exits and 1 client) will never work, because the minimum number of tor relays/authorities/exits needed to create a path through the network is 3. Clients do not participate in any of the 3 positions in a path - they only initiate the path. The basic-min network is already a minimal tor network containing: 3 authorities (which also act as non-exit relays) 1 exit 1 client ----- 5 tor instances You could possibly reduce this to: 1 authority (which also acts as a non-exit relay) 1 non-exit relay 1 exit 1 client ----- 4 tor instances I wouldn't recommend using 4 instances for two reasons: 1. The minimum number of authorities for a stable consensus is 3: A) more than one authority is needed to produce a genuine consensus; B) an odd number of authorities is needed to break ties. 2. The minimum number of authorities (or relays with AssumeReachable set) is 3, otherwise other relays or exits can't bootstrap. You can work around this by setting/uncommenting "AssumeReachable 1" in torrc_templates/common.i (It should be set to 1 by default.) I've never tested this, so I have no idea whether it will actually work. But feel free to try it, and let us know if it works (and please submit a new torrc_template file). Note: if you're using hidden services, you may need more than 3 authorities/relays/exits in the network. (I have not tested the minimum for hidden services.) -- What are you trying to simulate using chutney? -- Do you need to test the entire bootstrap process? (30 seconds to start up) Or do you just want the network to be ready quickly? (10 seconds to start up) To get these bootstrap speeds, you will need to use tor version 0.2.6.2-alpha or later, and the latest chutney from git. Otherwise, you will be looking at 45 seconds or more to bootstrap. It will help if you indicate what you've modified in the torrc files, and why. > > i use basic-min for configure. > ############## basic-min########################## > Authority = Node(tag="a", authority=1, relay=1, torrc="authority.tmpl") > Relay = Node(tag="r", relay=1, torrc="relay.tmpl") > Client = Node(tag="c", torrc="client.tmpl") > > NODES = Authority.getN(1) + Relay.getN(1) + Client.getN(1) > > ConfigureNodes(NODES) > <snip> teor

2 3

Proposal xxx: Consensus Hash Chaining
by Andrea Shepard 10 Jan '15

10 Jan '15

Here's a proposal Nick Mathewson and I just wrote for ticket #11157. --- Begin proposal body --- Filename: xxx-consensus-hash-chaining.txt Title: Consensus Hash Chaining Author: Nick Mathewson, Andrea Shepard Created: 06-Jan-2015 Status: Draft 1. Introduction and overview To avoid some categories of attacks against directory authorities and their keys, it would be handy to have an explicit hash chain in consensuses. 2. Directory authority operation We add the following field to votes and consensuses: previous-consensus ISOTIME [SP HashName "=" Base16]* NL where HashName is any keyword. This field may occur any number of times. The date in a previous-consensus line in a vote is the valid-after date of the consensus the line refers to. The hash should be computed over the signed portion of the consensus document. A directory authority should include a previous-consensus line for a consensus using all hashes it supports for all consensuses it knows which are still valid, together with the two most recently expired ones. When this proposal is implemented, a new consensus method should be allocated for adding previous-consensus lines to the consensus. A previous-consensus line is included in the consensus if and only if a line with that date was listed by more than half of the authorities whose votes are under consideration. A hash is included in that line if the hash was listed by more than half of the authorities whose votes are under consideration. Hashes are sorted lexically with a line by hashname; dates are sorted in temporal order. If, when computing a consensus, the authorities find that any previous-consensus line is *incompatible* with another, they must issue a loud warning. Two lines are incompatible if they have the same ISOTIME, but different values for the the same HashName. The hash "sha256" is mandatory. 3. Client and cache operation All parties receiving consensus documents should validate previous-consensus lines, and complain loudly if a hash fails to match. When a party receives a consensus document, it SHOULD check all previous-consensus lines against any previous consensuses it has retained, and if a hash fails to match it SHOULD warn loudly in the log mentioning the specific hashes and valid-after times in question, and store both the new consensus containing the mismatching hashes and the old consensus being checked for later analysis. An option SHOULD be provided to disable operation as a client or as a hidden service if this occurs. All relying parties SHOULD by default retain all valid consensuses they download plus two; but see "Security considerations" below. If a hash is not mismatched, the relying party may nonetheless be unable to validate the chain: either because there is a gap in the chain itself, or because the relying party does not have any of the consensuses that the latest consensus mentions. If this happens, the relying party should log a warning stating the specific cause, the hashes and valid-after time of both the consensus containing the unverifiable previous-consensus line and the hashes and valid-after time of the line for each such line, and retain a copy of the consensus document in question. A relying party MAY provide an option to disable operation as a client or hidden service in this event, but due to the risk that breaks in the chain may occur accidentally, such an option SHOULD be disabled by default if provided. If a relying party starts up and finds only very old consensuses such that no previous-consensus lines can be verified, it should log a notice of the gap along the lines of "consensus (date, hash) is quite new. Can't chain back to old consensus (date, hash)". If it has no old consensuses at all, it should log an info-level message of the form "we got consensus (date, hash). We haven't got any older consensuses, so we won't do any hash chain verification" 4. Security Considerations: * Retaining consensus documents on clients might leak information about when the client was active if a disk is later stolen or the client compromised. This should be documented somewhere and an option to disable (but thereby also disable verifying previous-consensus hashes) should be provided. * Clients MAY offer the option to retain previous consensuses in memory only to allow for validation without the potential disk leak. --- End proposal body --- -- Andrea Shepard <andrea(a)torproject.org> PGP fingerprint (ECC): BDF5 F867 8A52 4E4A BECF DE79 A4FF BC34 F01D D536 PGP fingerprint (RSA): 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5

4 5

[Patch] src/ext/tinytest_demo.c
by Gisle Vanem 08 Jan '15

08 Jan '15

The "compat.h" is needed due to the use of 'OP_EQ', etc: diff --git a/src/ext/tinytest_demo.c b/src/ext/tinytest_demo.c index c07f099..cfb524b 100644 --- a/src/ext/tinytest_demo.c +++ b/src/ext/tinytest_demo.c @@ -30,6 +30,7 @@ /* Make sure you include these headers. */ #include "tinytest.h" #include "tinytest_macros.h" +#include "compat.h" #include <stdio.h> #include <stdlib.h> -- --gv

1 0

Regarding involving in tor project
by dp docs 06 Jan '15

06 Jan '15

Dear Sir, I would like to get involved in the tor project and want to start working on the "TOR Codebase Cleanup" project. My IRC nickname is "sdpan21". I have registered my nickname there. But while asking any question, I am getting an error "can not send to channel". I have tried few suggestion from google to resolve this issue but none ofo them seems to wrking. I think Either i am am not resolving it properly or there problem is different in some sense. So I request , please help me resolving this issue. And guide me how can I get involved in the project mentioned above. I have good knowledge of c/c++ java python. please respond ASAP. I appreciate your effort for resolving the issue and for giving time to guide me. Thanks Durgesh Pandey.

4 6

how to simulate TOR network through chutney?
by Mohiuddin Ebna Kawsar 06 Jan '15

06 Jan '15

HI, I need to simulate TOR network in minimal case [1 ENTRY,1 RELAY,1 EXIT] node. how can i do that use chutney? how to setup exit node on my localhost and how to make circuit with that exit node? following are my config file with generated (slightly modified) torc files i use basic-min for configure. ############## basic-min########################## Authority = Node(tag="a", authority=1, relay=1, torrc="authority.tmpl") Relay = Node(tag="r", relay=1, torrc="relay.tmpl") Client = Node(tag="c", torrc="client.tmpl") NODES = Authority.getN(1) + Relay.getN(1) + Client.getN(1) ConfigureNodes(NODES) ########################Authority-000a torc ######################### TestingTorNetwork 1 DataDirectory /home/chutney-master/net/nodes/000a RunAsDaemon 1 ConnLimit 60 Nickname test000a ShutdownWaitLength 0 PidFile /home/chutney-master/net/nodes/000a/pid Log notice file /home/chutney-master/net/nodes/000a/notice.log Log info file /home/chutney-master/net/nodes/000a/info.log ProtocolWarnings 1 SafeLogging 0 DisableDebuggerAttachment 0 DirAuthority test000a orport=5000 no-v2 hs v3ident=32D2EB75473AB923F63D0D3C4B6929FC1BB658AE 127.0.0.1:7000 1DB6AEADE945A2EE1722A203CFED30478D0C8C82 SocksPort 0 OrPort 5000 Address 127.0.0.1 DirPort 7000 #NOTE: Setting TestingServerConsensusDownloadSchedule doesn't # help -- dl_stats.schedule is not DL_SCHED_CONSENSUS # at boostrap time. #TestingServerDownloadSchedule 10, 2, 2, 4, 4, 8, 13, 18, 25, 40, 60 # This file is named "relay.tmpl" for compatibility with previous # chutney versions # An exit relay that can exit to IPv4 & IPv6 localhost # (newer versions of tor need this to be explicitly configured) # An exit policy that allows exiting to IPv4 localhost ExitPolicy accept 127.0.0.0/8:* # An exit policy that allows exiting to IPv6 localhost ExitPolicy accept [::1]:* IPv6Exit 1 AuthoritativeDirectory 1 V3AuthoritativeDirectory 1 ContactInfo auth0(a)test.test ExitPolicy accept *:80 ExitPolicy accept *:443 ExitPolicy reject *:* TestingV3AuthInitialVotingInterval 300 TestingV3AuthInitialVoteDelay 20 TestingV3AuthInitialDistDelay 20 #TestingV3AuthVotingStartOffset 0 # Work around situations where the Exit and Guard flags aren't being set # These flags are set eventually, but it takes ~30 minutes # We could be more precise here, but it's easiest just to vote everything # Clients are sensible enough to filter out Exits without any exit ports, # and Guards without ORPorts # If your tor doesn't recognise TestingDirAuthVoteExit, update your chutney # to a version that includes the issue-13161-check-torrc-options features #TestingDirAuthVoteExit * #TestingDirAuthVoteGuard * #####################Relay 001r torc ############### TestingTorNetwork 1 DataDirectory /home/chutney-master/net/nodes/001r RunAsDaemon 1 ConnLimit 60 Nickname test001r ShutdownWaitLength 0 PidFile /home/chutney-master/net/nodes/001r/pid Log notice file /home/chutney-master/net/nodes/001r/notice.log Log info file /home/chutney-master/net/nodes/001r/info.log ProtocolWarnings 1 SafeLogging 0 DisableDebuggerAttachment 0 DirAuthority test000a orport=5000 no-v2 hs v3ident=32D2EB75473AB923F63D0D3C4B6929FC1BB658AE 127.0.0.1:7000 1DB6AEADE945A2EE1722A203CFED30478D0C8C82 SocksPort 0 OrPort 5001 Address 127.0.0.1 DirPort 7001 #NOTE: Setting TestingServerConsensusDownloadSchedule doesn't # help -- dl_stats.schedule is not DL_SCHED_CONSENSUS # at boostrap time. #TestingServerDownloadSchedule 10, 2, 2, 4, 4, 8, 13, 18, 25, 40, 60 # This file is named "relay.tmpl" for compatibility with previous # chutney versions # An exit relay that can exit to IPv4 & IPv6 localhost # (newer versions of tor need this to be explicitly configured) # An exit policy that allows exiting to IPv4 localhost ExitPolicy accept 127.0.0.0/8:* # An exit policy that allows exiting to IPv6 localhost ExitPolicy accept [::1]:* IPv6Exit 1 ExitPolicy accept *:80 ExitPolicy accept *:443 ExitPolicy reject *:* ######################### client 002c torc ########################## TestingTorNetwork 1 DataDirectory /home/chutney-master/net/nodes/002c RunAsDaemon 1 ConnLimit 60 Nickname test002c ShutdownWaitLength 0 PidFile /home/raboon/Thesis/chutney-master/net/nodes/002c/pid Log notice file /home/chutney-master/net/nodes/002c/notice.log Log info file /home/chutney-master/net/nodes/002c/info.log ProtocolWarnings 1 SafeLogging 0 DisableDebuggerAttachment 0 DirAuthority test000a orport=5000 no-v2 hs v3ident=32D2EB75473AB923F63D0D3C4B6929FC1BB658AE 127.0.0.1:7000 1DB6AEADE945A2EE1722A203CFED30478D0C8C82 SocksPort 9002 #NOTE: Setting TestingClientConsensusDownloadSchedule doesn't # help -- dl_stats.schedule is not DL_SCHED_CONSENSUS # at boostrap time. #TestingClientDownloadSchedule 10, 2, 2, 4, 4, 8, 13, 18, 25, 40, 60 ExitPolicy accept *:80 ExitPolicy accept *:443 ExitPolicy reject *:*

1 0

test_cmdline_args.py on Windows
by Gisle Vanem 06 Jan '15

06 Jan '15

There are some problems with 'run_tor()' and line-endings. It doesn't forsee any '\r\n' from 'Popen()' and since 'lines()' only splits on '\n', most of the tests fails. With this little patch: @@ -64,7 +64,7 @@ yield fp[i:i+4] def lines(s): - out = s.split("\n") + out = s.splitlines() I only get 2 errors in that script. The others like: self.assertTrue(out_verif.endswith("Configuration was valid\n")) needs another patch which is beyond my Python knowledge. -- --gv

4 6

Easy research tasks
by spriver 06 Jan '15

06 Jan '15

Hey everyone out there, as given in the topic, are there any easy research tasks to start with? Or is somewhere some help needed? Cheers, spriver

4 4

Re: [tor-dev] Tor BSD underperformance (was [Tor-BSD] Recognizing Randomness Exhaustion)
by teor 06 Jan '15

06 Jan '15

On 1 Jan 2015, at 07:39 , Greg Troxel <gdt(a)lexort.com> wrote: > Libertas <libertas(a)mykolab.com> writes: > >> Some of the people at tor-bsd(a)lists.nycbug.org and I are trying to >> figure out why Tor relays under-perform when running on OpenBSD. Many >> such relays aren't even close to being network-bound, >> file-descriptor-bound, memory-bound, or CPU-bound, but relay at least >> 33-50% less traffic than would be expected of a Linux machine in the >> same situation. > > I'm more familiar with NetBSD, but hopefully my comments are helpful. > >> For those not familiar, a Tor relay will eventually have an open TCP >> connection for each of the other >6,000 active relays, and (if it allows >> exit traffic) must make outside TCP connections for the user's requests, >> so it's pretty file-hungry and crypto-intensive. > > It may also have something to do with TCP. A few thoughts: > > * run netstat -f inet and look and the send queues. That's not really > cleanly diagnostic, but if they are all huge, it's a clue > > * run netstat -m and vmstat -m (not sure those map from NetBSD). Look > for runnig out of mbufs and mbuf clusters. Perhaps bump up > NMBCLUSTERS in the kernel if it's not dynamic. Tor 0.2.6.2-alpha (just in the process of being released) has some changes to queuing behaviour using the KIST algorithm. The KIST algorithm keeps the queues inside tor, and makes prioritisation decisions from there, rather than writing as much as possible to the OS TCP queues. I'm not sure how functional it is on *BSDs, but Nick Mathewson should be able to comment on that. (I've cc'd tor-dev and Nick.) teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w…

6 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev January 2015