- tor-dev - lists.torproject.org

Request to reschedule ooni dev meeting to Tuesday 13th
by Arturo Filastò 12 Jan '15

12 Jan '15

Hi, I have to study for an exam on Tuesday so it would be ideal for me if we could move the next ooni dev meeting to Tuesday. Does that work for those interested in attending? I would suggest we do it at the same time (19:00 CET). ~ Arturo

1 1

proposal 240: Early signing key revocation for directory authorities.
by Nick Mathewson 11 Jan '15

11 Jan '15

Filename: 240-auth-cert-revocation.txt Title: Early signing key revocation for directory authorities. Author: Nick Mathewson Created: 09-Jan-2015 Status: Draft 1. Overview This proposal describes a simple way for directory authorities to perform signing key revocation. 2. Specification We add the following lines to the authority signing certificate format: revoked-signing-key SP algname SP FINGERPRINT NL This line may appear zero or more times. It indicates that a particular not-yet-expired signing key should not be used. 3. Client and cache operation No client or cache should retain, use, or serve any certificate whose signing key is described in a revoked-signing-key line in a certificate with the same authority identity key. (If the signing key fingerprint appears in a cert with a different identity key, it has no effect: you aren't allowed to revoke other people's keys.) No Tor instance should download a certificate whose signing key,identity key combination is known to be revoked. 4. Authority operator interface. The 'tor-gencert' command will take a number of older certificates to revoke as optional command-line arguments. It will include their keys in revoked-signing-key lines only if they are still valid, or have been expired for no more than a month. 5. Circular revocation My first attempt at writing a proposal here included a lengthy section about how to handle cases where certificate A revokes the key of certificate B, and certificate B revokes the key of certificate A. Instead, I am inclined to say that this is a MUST NOT.

4 5

OnionMail ver. 1.8.0 is out.
by Liste 11 Jan '15

11 Jan '15

OnionMail is a mail server encrypted and anonymous made to run through the TOR network without losing the ability to communicate with the Internet. This type of server provides greater privacy for users and also protects against eavesdropping of the NSA or other threats. Important update OnionMail: News: New commands for SysOp with its help as RULEZ SYSOP. New commands for users (see file RULEZ). New scripts and tools included in the installation package OnionMail: onm-cli onm-srv onm-stat onm-new Wizard to add servers to the system OnionMail (onm-new): With this update, configure multiple instances of the same server OnionMail has never been easier. FRIEND command to force the cycle of friendship between the server (only sysop). New graphic themes for the web service: OnionMail is also available in black. Ability to select the output node prior to enrollment. Update Wizard for TAILS. Added the functions required by many SysOp. Configuring users via etc / users.conf. updates: Improved handling of thread. New features in the command line. Improvement of the HTTP server. Improved algorithm for networks of servers OnionMail. Bugs removed: Failure timeout connections and sessions with some parameters. We recommend the update: Use the update package (read instructions in readme.txt). see: http://onionmail.info -------------------------------------------------- --------- OnionMail è un server di posta criptato ed anonimo fatto per funzionare tramite la rete TOR senza perdere la possibilità di comunicare con internet. Questo tipo di server garantisce una maggiore privacy per gli utenti e protegge anche dalle intercettazioni del NSA o altre minacce. Importante aggiornamento di OnionMail: Novità: Nuovi comandi per i SysOp con relativo help come RULEZ SYSOP. Nuovi comandi per gli utenti (vedere file RULEZ). Nuovi script e tools inclusi nel pacchetto di installazione di OnionMail: onm-cli onm-srv onm-stat onm-new Wizard per aggiungere server OnionMail al sistema (onm-new): Con questo aggiornamento configurare più istanze di OnionMail sullo stesso server non è mai stato così facile. Comando FRIEND per forzare il ciclo di amicizia tra i server (solo SysOp). Nuovi temi grafici per il servizio web: OnionMail è disponibile anche in nero. Possibilità di selezionare il nodo di uscita prima dell'iscrizione. Aggionramento del wizard per TAILS. Aggiunte le funzioni richieste da molti SysOp. Configurazione degli utenti via etc/users.conf. Aggiornamenti: Migliorata la gestione dei thread. Nuove funzioni a riga di comando. Miglioramento del server HTTP. Migliorato l'algoritmo per le reti dei server OnionMail. Bugs Fixati: Mancato timeout delle connessioni e delle sessioni con alcuni parametri. Si consiglia l'aggiornamento: Usare il pacchetto di aggiornamento (leggere le istruzioni in readme.txt). Vedere: http://onionmail.info ----------------------------------------------------------- OnionMail es un servidor de correo encriptado y anónima hecha para funcionar a través de la red TOR sin perder la capacidad de comunicarse con Internet. Este tipo de servidor proporciona una mayor privacidad para los usuarios y también protege contra las escuchas de la NSA y otras amenazas. Importante OnionMail actualización: Noticias: Nuevos comandos para SysOp con su ayuda como RULEZ SYSOP. Nuevos comandos para los usuarios (ver archivo RULEZ). Nuevas secuencias de comandos y herramientas incluidas en el paquete de instalación OnionMail Asistente para agregar servidores al sistema OnionMail (ONM-nuevo): Con esta actualización, configurar varias instancias del mismo servidor OnionMail nunca ha sido tan fácil. AMIGO comando para forzar el ciclo de la amistad entre el servidor (sólo operador del sistema). Nuevos temas gráficos para el servicio web: OnionMail también está disponible en negro. Posibilidad de seleccionar el nodo de salida antes de la inscripción. Actualizar Asistente para COLAS. Añadido las funciones requeridas por muchos SysOp. Configuración de los usuarios a través etc / users.conf. Actualizaciones: Manejo mejorado de hilo. Las nuevas características de la línea de comandos. Mejora del servidor HTTP. Mejorado el algoritmo de redes de servidores OnionMail. Errores FIJACIÓN: Conexiones de tiempo de espera de fallo y sesiones con algunos parámetros. Se recomienda la actualización: Utilice el paquete de actualización (leer las instrucciones en el archivo readme.txt). ver: http://onionmail.info -------------------------------------------------- --------- OnionMail是不失與互聯網溝通的能力加密的郵件服務器和匿名發通過TOR網絡運行。這種類型的服務器提供更大的隱私，為用戶，也防止了NSA或其他威脅的竊聽。重要的更新OnionMail：新聞：對系統操作員的新命令其作為RULEZ SYSOP幫助。對於用戶新的命令（見文件RULEZ）。新的腳本和工具包含在安裝包OnionMail 嚮導將服務器添加到系統OnionMail（ONM-新）：此更新，配置OnionMail從未如此簡單在同一台服務器的多個實例。 FRIEND命令強制服務器（只有系統操作員）之間友誼的週期。新的圖形主題Web服務： OnionMail也提供黑色。能夠選擇之前報名輸出節點。更新嚮導尾巴。增加了許多系統操作員所需要的功能。通過ETC / users.conf配置用戶。更新：線程的處理得到改進。在命令行中的新功能。改進的HTTP服務器。改進算法的服務器OnionMail網絡。錯誤Fixati：故障超時連接和會話的一些參數。我們推薦的更新：使用更新包（讀readme.txt文件說明）。請參閱： http://onionmail.info -------------------------------------------------- --------- OnionMail는 인터넷과 통신 할 수있는 능력을 잃지 않고 TOR 네트워크를 통해 실행하게 메일 서버 암호화 익명이다. 서버 이러한 유형의 사용자를위한 더 큰 개인 정보를 제공하고, 또한 NSA 또 는 기타 위협의 도청을 방지합니다. 중요 업데이트 OnionMail : 뉴스 : RULEZ 시삽 등의 도움으로 시삽을위한 새로운 명령. 사용자를위한 새로운 명령 (파일 RULEZ 참조). 새로운 스크립트와 도구는 설치 패키지 OnionMail에 포함 마법사는 시스템에 OnionMail을 (onm 새로운) 서버를 추가합니다 : 이 업데이트를 쉽게 적이있다 OnionMail 동일한 서버의 여러 인스턴 스를 구성합니다. 친구 명령은 서버 (만 시삽) 사이에 우정의 사이클을 강제로. 웹 서비스를위한 새로운 그래픽 테마 : OnionMail는 블랙에서 사용할 수 있습니다. 등록하기 전에 출력 노드를 선택하는 능력. 냄 마법사를 업데이트합니다. 많은 시삽에서 필요로하는 기능을 추가했습니다. 등 / users.conf를 통해 사용자 구성. 업데이트 : 스레드의 처리 개선. 명령 행의 새로운 기능. HTTP 서버의 개선. 서버 OnionMail의 네트워크를위한 향상된 알고리즘. 버그를 제거 : 일부 매개 변수와 장애 시간 제한 연결 및 세션. 우리는 업데이트를 권장합니다 : (README.txt의 지침을 읽어) 업데이트 패키지를 사용합니다. 참조 : http://onionmail.info -------------------------------------------------- --------- OnionMail является почтовый сервер в зашифрованном виде и анонимно заставить работать через TOR сети без потери возможности общаться с Интернетом. Этот тип сервера обеспечивает большую конфиденциальность для пользователей, а также защищает от перехвата АНБ или других угроз. Важно OnionMail обновление: Новости: Новые команды для SysOp с его помощью, как Rulez SysOp. Новые команды для пользователей (см файла RULEZ). Новые сценарии и инструменты включены в инсталляционный пакет мог OnionMail Мастер добавления серверов к системе OnionMail (апт-новый): В этом обновлении, настроить несколько экземпляров одного и того же сервера OnionMail никогда не была проще. Команда друга, чтобы заставить цикл дружбы между сервером (только SysOp). Новые графические темы для веб-службы: OnionMail также доступна в черном цвете. Возможность выбора выходной узел до регистрации. Обновление мастера за хвосты. Добавлены функции необходимые для работы многих SysOp. Настройка пользователей с помощью и т.д. / users.conf. Обновления: Улучшена обработка нити. Новые возможности в командной строке. Усовершенствование сервера HTTP. Улучшен алгоритм для сетей серверов OnionMail. Ошибки удалены: Отказ тайм-аут соединения и сессии с некоторыми параметрами. Мы рекомендуем обновление: Используйте пакет обновления (читать инструкции в readme.txt). Увидеть: http://onionmail.info -------------------------------------------------- ---------

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 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