- tor-dev - lists.torproject.org

Weather post-GSoC
by meejah 31 Aug '14

31 Aug '14

Now that GSoC is over, there are some things that should be accomplished in the Tor Weather codebase soon to reach "deployment": 1. remove local copy of OnionPy and replace with real thing 2. (ideally automated) front-end tests 3. ensure production and Vagrant setup are as close as possible 4. tests with dump/copy of live database Less important, but still Very Nice To Have: 5. more unit-test coverage would be nice too 6. nicer-looking HTML I do not have enough spare cycles to accomplish all these things myself. I will commit to rapidly reviewing/merging to the "develop" branch any pull-requests. If any of the above sounds interesting, please follow-up here (or in #tor-dev). Thanks, meejah

2 5

DNSSEC
by merc1984＠f-m.fm 31 Aug '14

31 Aug '14

Does anyone know why TOR does not use DNSSEC? The only documentation I found on the TORProject website for DNS does not actually explain how DNS works on TOR. I infer it must be TCP, as TOR can not do UDP, and I imagine that relay nodes must be the resolvers in order to resolve .onion domains. But beyond that there is no information on how it works. Seems to me that the lack of DNSSEC in TOR is a gigantic security hole. (DNS cache poisoning) -- http://www.fastmail.fm - Access your email from home and the web

3 2

Gpg subkey for deb.torproject.org archive expired
by Lampshade 30 Aug '14

30 Aug '14

pub 2048R/886DDD89 2009-09-04 [expires: 2014-09-03] Key fingerprint = A3C4 F0F9 79CA A22C DBA8 F512 EE8C BC9E 886D DD89 uid deb.torproject.org archive signing key sub 2048R/219EC810 2009-09-04 [expires: 2014-08-29] Above text is from https://www.torproject.org/docs/signing-keys.html.en Today is 30 august, so subkey expired and master key is going to expire soon. Please generate new keys for Debian and Ubuntu users, of course in secure manner.

2 1

Re: [tor-dev] problems building on osx 10.9.4
by Tim 30 Aug '14

30 Aug '14

Hi Alan, Apologies for the overlapping reply to your last question - I'm still catching up. Chutney on OS X I can successfully run chutney with the following environmental variables set: PYTHON=python CHUTNEY_PATH=/path/to/chutney make test-network I then a lot of output, which ends with this result: Verifying data transmission: Success You may wish to permanently set PYTHON and CHUTNEY_PATH in your ~/.bashrc using: export PYTHON=python export CHUTNEY_PATH=/path/to/chutney You may need to supply the full path to python, but it's unlikely. For the record, I'm using python 2.7.8 from MacPorts to match some libraries I have installed. coverage-html on OS X For what it's worth, when I first tried to run make coverage-html on my os x setup, I get output ending with: lcov --capture --rc lcov_branch_coverage=1 --no-external --directory . --output-file "./coverage_html/lcov.tmp" Capturing coverage data from . Found gcov version: 4.2.1 Scanning . for .gcda files ... geninfo: WARNING: no .gcda files found in . - skipping! Finished .info-file creation lcov --remove "./coverage_html/lcov.tmp" --rc lcov_branch_coverage=1 'test/*' 'ext/tinytest*' '/usr/*' --output-file "./coverage_html/lcov.info" Reading tracefile ./coverage_html/lcov.tmp lcov: ERROR: no valid records found in tracefile ./coverage_html/lcov.tmp make: *** [coverage-html] Error 255 This was because my configure invocation didn't include the test coverage option: ./configure --with-libevent-dir=/opt/local --with-openssl-dir=/opt/local --enable-coverage --disable-asciidoc The documentation is successfully produced with: make clean && make && make test && make coverage-html Overall coverage rate: lines......: 33.6% (16872 of 50276 lines) functions..: 47.5% (1590 of 3350 functions) branches...: 23.7% (9708 of 40978 branches) As I said, I've used MacPorts - https://www.macports.org/ - to install: $ port list lcov libevent openssl lcov @1.11 devel/lcov libevent @2.0.21 devel/libevent openssl @1.0.1i devel/openssl You may wish to switch to lcov 1.11 if your version is giving you grief on OS X. So it appears there is no need to switch to Linux just yet… you'll run into similar configuration issues on any platform :-) Tim On 30 Aug 2014, at 13:22 , tor-dev-request(a)lists.torproject.org wrote: > Date: Fri, 29 Aug 2014 13:29:30 -0400 > From: Alan Fay <emptyset(a)freesideatlanta.org> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] problems building on osx 10.9.4 > Message-ID: > <CAFC4BBwOHTPrCZ6yT7-4i_6AYwnqGuqpUeLue=MAW7xdJF7o_Q(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Arlo, > > Thanks, I got the build working with a local build/path of libevent2, just > as you described. I used brew for the other dependencies. > > I am able to run ./scripts/test/coverage coverage-output without problems, > but running: > $ make coverage-html > > Has the following problem: [ > http://0bin.net/paste/9DYCmagMbr8HNiw4#rtSQ-ia0BrOS1nzilEVu3dBlUKrenXGRyVXD… > ] > gcov doesn't have a -v switch, just -version (this was from lcov installed > via $ brew install lcov) > > I got chutney after a little bit of searching. The documentation doesn't > make clear that chutney is part of the tor projects, located here: [ > https://gitweb.torproject.org/chutney.git] > > One of errors I get from running $ make test-network is: > ./chutney: line 4: python2: command not found > > This looks like a platform problem. That's why I'm wondering if it's > better to work on this code on some flavor of Linux system instead of osx. > > Thanks, > Alan

1 0

problems building on osx 10.9.4
by Tim 30 Aug '14

30 Aug '14

Alan, When building tor from the latest git sources on OS X 10.9.4, I have found that I need to: * install libevent, * install a newer version of OpenSSL (the system version is missing a symbol), and * disable man page generation. (Alternately, there are further tools that need to be installed to build the man pages.) I use the following configure invocation, for an installation in /opt/local (it looks like you're using /usr/local ): ./configure --with-libevent-dir=/opt/local --with-openssl-dir=/opt/local --disable-asciidoc I use MacPorts - https://www.macports.org/ - as a package manager, and have the following versions of the libraries installed: $ port list openssl libevent openssl @1.0.1i devel/openssl libevent @2.0.21 devel/libevent Let us know how you go. Tim On 29 Aug 2014, at 13:49 , tor-dev-request(a)lists.torproject.org wrote: > Date: Thu, 28 Aug 2014 12:33:59 -0400 > From: Alan Fay <emptyset(a)freesideatlanta.org> > To: tor-dev(a)lists.torproject.org > Subject: [tor-dev] problems building on osx 10.9.4 > Message-ID: > <CAFC4BBxo0zAeDe6n_=JgN_sagiN=DaYN0GRBJLpkZb6W90d73Q(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello! > > I'm trying to get a working build of Tor so I can learn more about working > on item "m. Improve test coverage in Tor". Apologies ahead of time for > being green; this seemed to be the most accessible place to start > contributing...I read through doc/HACKING and I'm slowly working through > that. > > I'm running osx 10.9.4. I ran: > > $ ./autogen.sh > $ ./configure > ... > checking for libevent directory... configure: WARNING: We found the > libraries for libevent, but we could not find the C header files. You may > need to install a devel package. > configure: error: Missing headers; unable to proceed. > > I installed libevent-2.0.21-stable from source, and then nickm on #tor-dev > helped me see some permissions issues in /usr/local/include/event2 and > /usr/local/lib/libevent* ; please see: [ > http://0bin.net/paste/fuObUINKL1EOICf8#jJuGjo2wv65-7QNcHLGBcFPsNdAwhRlWmg6O… > ] > > I found reference to this error on the tor-relay mailing list here, but I > didn't get far with any of those suggested fixes, and it's also for osx > 10.4. This is the first hit when I google the error: [ > https://lists.torproject.org/pipermail/tor-relays/2012-January/001192.html] > > Thanks, > Alan >

1 0

[GSoC] Revamp GetTor summary
by ilv 30 Aug '14

30 Aug '14

Hi! First of all, I want to thank the people at tor-dev that make this happen every year, it was an awesome experience and I sincerely hope to be around for a long time. I also want to thank my mentor Sukhbir for always being around to solve doubts and checking up my progress, and to my co-mentor Nima for his always useful advices and comments. Secondly, I would like to give you a brief summary of what I did during this 3-4 months: 1) Rewrote GetTor from scratch. Now it should be easier to add new ways to distribute download links for TBB. 2) Created two components for this new GetTor: SMTP and XMPP. 3) Enabled the (old) multilingual feature. Now you can receive replies in your language (in case translation exists). 4) Created a component to automatically upload TBB to Dropbox. 5) Enabled basic blacklisting of users. It basically prevents flood by specifying a limit of requests during a certain period of time. 6) Added a small SQLite database for 5) and to get some stats. No real info about the addresses/accounts stored. I would really appreciate any feedback on the work done, specially about the points 5) and 6). Do these points make sense to you? The plan for now is to keep doing tests and deploy it asap (hopefully during September). As always, you can check the code on [0]. That would be for now, have a nice weekend! [0] https://github.com/ileiva/gettor/tree/master/src Best, -- 4096R/540BFC0E

1 0

problems building on osx 10.9.4
by Alan Fay 29 Aug '14

29 Aug '14

Hello! I'm trying to get a working build of Tor so I can learn more about working on item "m. Improve test coverage in Tor". Apologies ahead of time for being green; this seemed to be the most accessible place to start contributing...I read through doc/HACKING and I'm slowly working through that. I'm running osx 10.9.4. I ran: $ ./autogen.sh $ ./configure ... checking for libevent directory... configure: WARNING: We found the libraries for libevent, but we could not find the C header files. You may need to install a devel package. configure: error: Missing headers; unable to proceed. I installed libevent-2.0.21-stable from source, and then nickm on #tor-dev helped me see some permissions issues in /usr/local/include/event2 and /usr/local/lib/libevent* ; please see: [ http://0bin.net/paste/fuObUINKL1EOICf8#jJuGjo2wv65-7QNcHLGBcFPsNdAwhRlWmg6O… ] I found reference to this error on the tor-relay mailing list here, but I didn't get far with any of those suggested fixes, and it's also for osx 10.4. This is the first hit when I google the error: [ https://lists.torproject.org/pipermail/tor-relays/2012-January/001192.html] Thanks, Alan

2 2

Catch probability of EE node greater than G and E node
by saurav dahal 29 Aug '14

29 Aug '14

Hello, The following is the default Tor network in shadow simulator: Total BW of Guard flagged nodes=258.15 MB/S Total BW of Middle nodes=23.69 MB/S Total BW of Exit flagged nodes=13.23 MB/S Total BW of Guard+Exit flagged nodes=213.4 MB/S *1st Case:* I inserted 40 guard nodes and 40 exit nodes, each of 5 MB/S in above Tor network and performed the simulation. Following are the bandwidth weights derived from the consensus document of webclient when Guard and Exit nodes of 5MB/S are added separately: Wbd=1454 Wbe=0 Wbg=4882 Wbm=10000 Wdb=10000 Web=10000 Wed=7091 Wee=10000 Weg=7091 Wem=10000 Wgb=10000 Wgd=1454 Wgg=5118 Wgm=5118 Wmb=10000 Wmd=1454 Wme=0 Wmg=4882 Wmm=10000 *2nd Case:* I added 80 Guard-Exit (EE) nodes, each 5MB/S and perform the simulation. Following are the bandwidth weights derived from the consensus document when EE nodes of 5MB/S are added: Wbd=4722 Wbe=0 Wbg=0 Wbm=10000 Wdb=10000 Web=10000 Wed=4826 Wee=10000 Weg=4826 Wem=10000 Wgb=10000 Wgd=452 Wgg=10000 Wgm=10000 Wmb=10000 Wmd=4722 Wme=0 Wmg=0 Wmm=10000 I calculated catch probability i.e., probability that a client chooses my inserted nodes in both guard and exit position, in both cases and found that the 2nd case yields more probability. By examining the above weights, how it is possible that the catch probability for EE nodes are much higher than those of guard and exit node separately? OR is there any other reason for this? Can anybody please explain this? Thanks, -- Saurav

1 0

Bandwidth Weighted Node selection algorithm
by saurav dahal 29 Aug '14

29 Aug '14

Hello, In the paper, "Zhen Ling; Junzhou Luo; Wei Yu; Ming Yang; Xinwen Fu, "Extensive analysis and large-scale empirical evaluation of tor bridge discovery," *INFOCOM, 2012 Proceedings IEEE* , vol., no., pp.2381,2389, 25-30 March 2012", the author has mentioned about Bandwidth Weighted Node selection algorithm. He has mentioned about bandwidth weights WG and WE, responsible for node selection. But in the Tor directory protocol version 3, there is no such mention of these weights but rather there are other weights such as Wgg, Wee, etc. Can anybody please elaborate on this? Thanks, -- Saurav

2 2

Prototype Primitives for Website Traffic Fingerprinting defenses
by Mike Perry 28 Aug '14

28 Aug '14

Hello all, What follows is a summary of the primitives that Marc Juarez aims to implement for his Google Summer of Code project on prototyping defenses for Website Traffic Fingerprinting and follow-on research. After a review of Tamaraw[1], Adaptive Padding[2], CS-BuFLO[3], and the Supersequence[4] work, as well as some discussion at the Tor dev meeting, we came up with this list of padding message primitives. These functions are meant to be sent as command cells from one endpoint to the other. Some are bidirectional commands, others can only be sent in one direction (client to relay, or relay to client). For now, they will be implemented as ad-hoc messages between two modified obfsproxy (called wfpadtools) instances. The source code for this fork lives here for the moment: https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools/ Long term, I am thinking that all of these should be specified as if they were their own RELAY_* cell type from tor-spec.txt: https://gitweb.torproject.org/torspec.git/blob/HEAD:/tor-spec.txt#l1215 This means that padding would be a circuit-level property, and it would be possible to send it to and from any hop in the circuit, due to leaky-pipe topology (using the "recognized" field). In a world of very cheap and excessive middle and Guard node bandwidth, we would run this padding to the middle node. For the wfpadtools prototype, it will obviously only cover the first hop. Here's the list of primitives, broken down by research paper: Generic Messages (common to all defenses): RELAY_IGNORE() Description: Simple fixed-length (CELL_SIZE) padding cell. Direction: Bidirectional (client to relay, relay to client) Parameters: None RELAY_SEND_PADDING(N,t) Description: Send the requested number of padding cells in response. Direction: Client to relay Parameters: N: Number of padding cells to send in response to this cell t: microseconds delay before sending RELAY_APP_HINT(session_id, status) Description: A hint from the application layer for session start/stop Direction: Client to relay Parameters: session_id: A string identifying the session (ie keyed hash of url bar domain) status: "Start" or "Stop", indicating session start and end. Adaptive Padding Messages: RELAY_BURST_HISTOGRAM(histogram[], labels_ms[], remove_toks, fuzz, when) Description: Specifies a histogram that encodes a delay distribution representing the probability of sending a single padding packet after a given delay in response to either an upstream cell, or a client-originating cell. Direction: Client to relay Parameters: histogram[]: Contains delay distribution of sending an IGNORE packet after sending a real packet labels_ms[]: millisecond labels for the bins (with "Infinity"/"Ignore" bin to allow encoding the probability of not sending any padding packet in response to this packet). remove_toks: If true, follow Adaptive Padding token removal rules. If false, histograms are immutable. fuzz: If true, randomize the delay uniformly between bin labels. If false, use bin lables as exact delay values. when: If set to "receive", this histogram governs the probably of sending a padding packet after some delay in response to a packet originating from. If set to "send", this histogram governs padding packets that are transmitted after a packet arrives from upstream (the middle node). In both cases, the padding packet is sent in the direction of the client. RELAY_GAP_HISTOGRAM(histogram[], labels_ms[], remove_toks, fuzz, when) Description: Specifies a histogram that encodes a delay distribution representing the probability of sending a single additional padding packet after a given delay following a padding packet that originated at this hop. Direction: Client to relay Parameters: histogram[]: Contains delay distribution of sending an IGNORE packet after sending an IGNORE packet labels_ms[]: millisecond labels for the bins (with "Infinity"/"Ignore" bin to allow encoding the probability of not sending any padding packet in response to this packet). remove_toks: If true, follow Adaptive Padding token removal rules. If false, histograms are immutable. fuzz: If true, randomize the delay uniformly between bin labels. If false, use bin lables as exact delay values. when: If "receive", this histogram applies to locally-inserted padding packets that were initially sent in response to client-originated data. If "send", this histogram applies to packets sent in response to locally-inserted padding packets sent in response to upstream data. Note that this means that implementations must maintain this metadata as internal state as the system transitions from BURST_HISTOGRAM initiated padding into GAP_HISTOGRAM initiated padding. In both cases, the padding packet is sent in the direction of the client. CS-BuFLO Messages: RELAY_TOTAL_PAD(session_id, t): Description: Requests that endpoint pad all batches to nearest 2^K cells total or until APP_HINT(session_id, stop) Direction: Client to relay Parameters: session_id: The session ID from APP_HINT() t: The number of microseconds to wait between cells to consider them part of the same batch. RELAY_PAYLOAD_PAD(session_id, t, R): XXX: The paper was not clear enough for me to understand this primitive Tamaraw: RELAY_BATCH_PAD(session_id, L, t) Description: Requests that endpoint pad all batches of cells to L cells total or until APP_HINT(session_id, stop) Direction: Client to relay Parameters: session_id: The session ID from APP_HINT() L: The multiple of cells to pad to. t: The number of microseconds to wait between cells to consider them part of the same batch. Comments, questions, and suggestions are welcome! In particular, I'm not sure I got either the CS-Buflo or the tamaraw primitives completely correct. 1. http://cacr.uwaterloo.ca/techreports/2013/cacr2013-30.pdf 2. http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf 3. http://arxiv.org/abs/1401.6022 4. http://cacr.uwaterloo.ca/techreports/2014/cacr2014-05.pdf -- Mike Perry

1 2