- tor-dev - lists.torproject.org

Questions pertaining to client to directory authority communications
by Jon Smithe 19 May '13

19 May '13

Hello! I have been reading through the various tor specifications trying to understand how this all works, so please forgive any ignorance of the protocol on my part. There seems to be a fair amount of gaps about specifically how various communications take place; for instance if we consider the very beginning of the communication chain, Directory Authorities, we have the dir-spec.txt file which outlines rather well what type of information can be retrieved from the directories, but not what communication protocol is actually being used. It appears that the usage of HTTP is fairly inherent, but this seems like it is only a partial answer as only some of the trusted authorities seem to speak HTTP on the address & port combination compiled into tor, moreover at least some of the authorities do not appear to implement the specification entirely. For instance, the trusted authority at MIT, 'morial' is listening on port 9131, however attempting to retrieve the network status document from it via a GET request to /tor/status/all.z results in no output at all. I would assume if this was a matter of needing to connect via SSL that I would receive an error due to a bad handshake, but I get nothing back. This holds true for at least one of the other trusted authorities listening on a non-HTTP related port (turtles). So for those servers, exactly what protocol is being used and is it documented anywhere other than the source code? Then, for instance, if we connect to 'tor26', which does respond to HTTP requests and attempt to retrieve a v2 network status document via the /tor/status/all.z URI, we receive a 404 although it appears the document that should exist there exists on other URIs, it's not entirely clear if this is just outdated code, specific to particular versions of the protocol (tor26 does have the no-v2 flag set which might be the issue?) or what exactly. So the question is, are there accurate specifications anywhere that focus not only on the semantics of cryptography and rationale behind certain choices but also the specifics of how exactly the protocol works or am I 'stuck' with reading the source code? I suspect that it is the later, so my question would be is there anyplace where the control flow is somewhat documented? (As the flow is somewhat disjointed at least in part to the way libevent works and other such aspects that make it difficult to parse if you're not familiar already with how everything is interconnected). I have other questions about aspects of the protocol, but I will mostly save those until I understand the basic blocks of it better. But to exemplify somewhat, it does seem that the introduction of guard nodes would cause an inverse of desired effect; there appears to be about 1000-1100 guard nodes versus a several thousand relays, and about 800-900 exit nodes so it would seem that mitigating the attack where an attacker controlled C number of nodes is essentially pointless as one would only need to control a set number of guard and exit nodes and can more or less ignore the relays in between, so whereas you needed say C/N nodes previously, one would only need Cg/Ng (Cg controlled guards / Ng Number of guards). If we then factor in that it seems possible that a guard or relay can essentially indirectly control the route a circuit takes through the network by continually causing cell extensions to fail for all relays and exit nodes that they do not control, then the value for Cg would seem to not need to be overly large or at least not approach the values of C or Cg (C/N or Cg/Ng). This seems incredibly reasonable for attackers that have state level resources (What is 1,000 computers to China? Iran? ...the United States?) and because the algorithm for selecting guards appears to be based entirely on stability and bandwidth; metrics we can expect a government to have plenty of on hand. I understand that rotation is supposed to ease this somewhat, but at least according to the academic paper out of Waterloo that Roger co-authored, it would appear that this actually facilitates the compromise of more clients than eases the problem, with the most secure (in the lab) situation being a single guard. (I understand that in practice this will not be realistic as it creates a bottle-neck in a variety of ways, e.g. firewalls and DDoS). I suspect many of the questions I have will be answered as I better familiarize myself with the protocol, so of the few I've enumerated, they can be thought of exemplifications that I expect will hash themselves out as I progress through the source and specifications. Thanks a lot! Jon

3 2

Your server has not managed to confirm that its ORPort is reachable
by Christian Kujau 19 May '13

19 May '13

Hi, I had to reboot my bridge for a (Ubuntu) kernel upgrade but now it cannot confirm that the ORPort is accessible: May 17 20:20:36.000 [notice] Tor 0.2.4.12-alpha (git-a1bb0df9be95ce7a) opening log file. May 17 20:20:36.000 [notice] Not disabling debugger attaching for unprivileged users. May 17 20:20:36.000 [notice] Your Tor server's identity key fingerprint is '...' May 17 20:20:36.000 [notice] Configured hibernation. This interval began at 2013-05-13 10:00:00; the scheduled wake-up time was 2013-05-13 10:00:00; we expect to exhaust our quota for this interval around 2013-05-20 10:00:00; the next interval begins at 2013-05-20 10:00:00 (all times local) May 17 20:20:36.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. May 17 20:20:37.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. May 17 20:20:37.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. May 17 20:20:40.000 [notice] We now have enough directory information to build circuits. May 17 20:20:40.000 [notice] Bootstrapped 80%: Connecting to the Tor network. May 17 20:20:41.000 [notice] Bootstrapped 85%: Finishing handshake with first hop. May 17 20:20:41.000 [notice] Bootstrapped 90%: Establishing a Tor circuit. May 17 20:20:42.000 [notice] Registered server transport 'obfs3' at '0.0.0.0:30001' May 17 20:20:42.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:20001' May 17 20:20:43.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. May 17 20:20:43.000 [notice] Bootstrapped 100%: Done. May 17 20:20:43.000 [notice] Guessed our IP address as ... (source: ...). May 17 20:40:43.000 [warn] Your server (...:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. I have not changed my tor configuration (honest! :-)) and Tor 0.2.4.12-alpha (from deb.torproject.org) was running fine before. This particular bridge is running inside an Amazon EC2 instance and I can reach port 9001 from the outside: $ nc -w1 -vnz xx.18.xx.xxx 9001 Connection to xx.18.xx.xxx 9001 port [tcp/*] succeeded! And I can see that request on the bridge when tcpdump'ing :9001, so it's not a network issue. I'm not sure what "/etc/hosts" should have to do with it, but I haven't modified this either. I'm strace'ing the tor process now to see what it's doing but couldn't find anything suspicious so far. Any thoughts? Christian. -- BOFH excuse #139: UBNC (user brain not connected)

2 3

Tor Browser source tarball not available
by Jamie Nguyen 15 May '13

15 May '13

Hi, the source at this link is missing: https://www.torproject.org/dist/torbrowser/tor-browser-2.3.25-8-src.tar.gz I'd be very grateful if someone could upload it please. Kind regards, -- Jamie Nguyen

1 0

Status of Torouter project
by Griffin Boyce 14 May '13

14 May '13

Hello all, So I'm part of a team working on wireless mesh, and Torouter has come up a few times this week. Is it actively being developed? Given the state of the roadmap [1], I'd sort of assumed it was inactive or on hiatus, but others had heard differently. thanks, Griffin Boyce -- Technical Program Associate, Open Technology Institute #Foucault / PGP: 0xAE792C97 / OTR: saint(a)jabber.ccc.de

4 5

BridgeDB - Bridge Distribution Modifications
by Matthew Finkel 14 May '13

14 May '13

Hi all, Over the last few weeks I've been working with George and Aaron on updating BridgeDB's code with respect to how it handles pluggable transports. I've made some decent progress, but there are some questions that I'd like to ask (because I'm not sure I should be the one making the decision). I've also started updating the spec and there are some parts on which I'd like some clarification. I'll try to summarize the thoughts on the matter we/I have thus far. See [A] if you're unfamiliar with the BridgeDB code/spec/idea. 1) How should BridgeDB decide the number of transports, and types, it should hand out? - My current patch returns transports based on the ratio of how many there are compared to the other bridges, so that if we hand out four bridges and obfs2 bridges account for 3/10 of all running bridges, then BridgeDB will hand out (4*(3/10)) = 1.2 bridges with each request, on average. - I've also added an option into bridgedb.conf to set the (expected) minimum and maximum number of bridges which support a specific PT that BridgeDB should hand out per request. - I have a verification check that tries to force us to meet these values, however, with its current implementation it's not guaranteed, only probabilistic. I think this is okay for now. - So, is this enough? Do we want/need a deterministic method of supplying bridges with a supported set of transports? - Another option is to place each transport into its own subring and select from each of the subrings to ensure we meet the requirement. The more I've thought about this, the more I think this defeats the purpose of constructing the rings, though. - Last (for now), if a bridge supports multiple PTs, should we return all of them to the user or randomly select one or select one with a bias? We agreed that we really shouldn't do the first because that would just accelerate the ability of a censor to block more bridges. The middle option works, but given that many bridges now support obfs2 and obfs3, is it a good idea to, again, probabilistically return each type (roughly) half the time? 2) Should we prefer to distribute PT bridges over regular bridges which have their ORPort on 443? - Right now returning ORPorts on 443 is the highest priority and transports are a secondary best-effort operation. 3) Unless I incorrectly understand the code, the bridges never rotate. The bridge interval is set to NoSchedule(), which means it returns a static time. Is there a reason for this? This is counter to the spec. Just wondering. :) (I had some other points I wanted to raise, but I'm blanking on them now. I think this is a good start, though.) Please also let me know and correct anything I may have gotten wrong. Thanks everyone, and thanks to George and Aaron for their help, as well. - Matt A. For those who don't know the details of the code, the simplified version is as follows: 1) All bridges send their bridge descriptors and misc information to the Bridge Authority. 2) Bridge Authority provides a network status file containing all known bridges described by their name, fingerprint, digest, time of publication, IP addr, ORPort, DirPort. Bridge Auth also provides a bridge descriptor file also specifying the bridges IP addr, ORPort, and fingerprint. Last, it supplies an extra-info file that contains all the extra info that the bridges provide - mainly their transports, in our case. 3) BridgeDB parses all of these files and associates the information to a single instance of a bridge. 4) BridgeDB assigns each running bridge to a distributor (website, email, etc) based on an hmac of the bridge's ID. Once assigned, the bridge is inserted into the distributors list of bridges. 5) BridgeDB then further organizes the bridges assigned to each distributor by moving them into rings and subrings. - A ring is simply a sorted list of an hmac of the bridges' ID which, when traversed, wraps around to the beginning if it ever reaches the end. - The hmac of the bridge's ID is used to retrieve the actual bridge instance from a hash, which is stored along side the ring. 6) Some distributors, such as https, are 'initialized' with a few rings based on filters. - https starts out with a ring containing all bridges assigned to it, a ring only containing bridges which support IPv4 connections, and a ring only containing bridges which support IPv6 connections. - Every ring also contains two subrings (currently). One subring is the subset of bridges from the parent ring which have their ORPort listening on port 443. The other subring is the subset of bridges from the parent ring which have the stable flag set. - For example, - Cluster 1 Ring - subring (stable) - subring (https) - Cluster 2 Ring - subring (stable) - subring (https) - IPv4 Cluster 1 Ring - subring (stable) - subring (https) - IPv4 Cluster 2 Ring - subring (stable) - subring (https) - IPv6 Cluster 1 Ring - subring (stable) - subring (https) - IPv6 Cluster 2 Ring - subring (stable) - subring (https) 7) When BridgeDB receives a request for bridges from its website, it forwards the query on to the IP distributor. The details will include if a specific PT was requested, IP version bridge supports, country within which the bridge should not be blocked, requesing IP address, and interval. 8) The distributor then decides on the "area" of the IP address, currently the /24 mask, and then finds the "cluster" within that area (by taking the first eight bytes of an hmac of the area and using the result (modulus "the number of clusters")). A filter is then constructed based on the requested information. If a ring already exists that satisfies exactly these filters then that is then constructed based on the requested information. If a ring already exists that satisfies exactly these filters then that is used. Else a new ring (with subrings) is constructed to satisfy this request. The distributor also computes the position in the ring as the hmac of the interval and the area. 9) Once the correct ring exists, it determines how many bridges it can find in the ring's subrings to satisfy the request. This is done by taking the previously computed position and finding it in the list of bridges ID's hmacs and then selecting the next consecutive "requested number of bridges" from the list (wrapping around to the beginning, if necessary). The same is then done for the main ring. The results from these searchs are then joined and the first "requested number of bridges" unique keys are selected from the list. This list is then sorted and returned, propagating back up to the user. 10) Similar actions are taken by the other distributors. For example, the email distributor doesn't use an "area" to decide which bridges to distribute, it uses the normalized requesting/source mail address. 11) Misc: - Because the rings are sorted by an hmac of the bridge's ID, I expect that they will be uniformly distributed around the ring. As such, I don't expect there to be a bias for one type of bridge/transport/ORPort over any other. (Is this incorrect?)

2 2

txtorcon 0.8.0
by meejah 14 May '13

14 May '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 txtorcon 0.8.0 is now tagged and released. [1] txtorcon is a Python+Twisted-based asynchronous implementation of the Tor control protocol. It includes a state-tracking abstraction, configuration abstraction, Twisted endpoint support for hidden services, 96%+ unit-test coverage and many examples. New in this release: . issue #18: slight *API change* ICircuitListener.circuit_failed, circuit_closed, IStreamListener.stream_failed, stream_closed and stream_detach all now include any keywords in the notification method (these either lacked flags, or only included some) . launch_tor() can take a timeout (starting with a patch from hellais); . cleanup from aagbsn; . more test coverage; . run tests cleanly without graphviz (from lukaslueg); . issue #26: fix from lukaslueg; . pep8 and whitespace targets plus massive cleanup (now pep8 clean, from lukaslueg); . issue #30: fix reported by webmeister making ipaddr actually-optional; . example using synchronous web server (built-in SimpleHTTPServer) with txtorcon (from lukaslueg); . TorState can now create circuits without an explicit path; . passwords for non-cookie authenticated sessions now use a password callback (that may return a Deferred); . fixes for AddrMap in case Tor ticket #8596 is implemented; Code and built documentation may be obtained: git clone git://github.com/meejah/txtorcon.git https://github.com/meejah/txtorcon https://txtorcon.readthedocs.org/en/latest/index.html You may easily install it: pip install txtorcon easy_install txtorcon The sha256sum output is: 87fcb3bce3ac3b48583f637bf69445bd50071411dc3fded89df7600d870a3094 txtorcon-0.8.0.tar.gz thanks, meejah [1] -- (Note the tagging took place last month, and I've only now updated PyPI, ReadTheDocs, freecode, emailed this, ...) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJRjy+yAAoJEJ0UOBRRgEVQXrMH/0Kl3DmVLyqo3aTBNv1d50RL yi8u5LTZLNtuYiyJsxqTFyq8zNhfEwIPoXbsqHyNuv0hv8s6Qn4OkXh47/crhukO GpnNNTldvSQIpOfNw+ftCYF/NC0X5pOjJo/Rz1XUkFyms50cqq17i+MWvcAvaFnW Ols6+7ulh8u61ElafVxnwn1zgitkpUOOsnF8a27iXryFJ/iZFFROnCigJv2eM8pj SqcwKbVp9h1VtztoYhtEcjEPBm1NnrYGoRIjh9D3RQfEVnXgM2fU4HoGhFAqYj7M wFZv0DZBvL2s/XwV8PEi4Y4+fTJZTXE7bbHctMWjUWjhlMfMniq2oud4hZJ5ugY= =MDAq -----END PGP SIGNATURE-----

1 1

Tor Launcher UI feedback follow up
by Mark Smith 13 May '13

13 May '13

Thank you to everyone who provided feedback on the Tor Launcher UI. It has been very helpful to us and we made a lot of changes based on it. The most significant change was the addition of an initial question to the "first run" settings wizard, which allows people to skip all of the detailed questions and quickly connect. Take a look here: http://trial.pearlcrescent.com/tor/torlauncher/2013-05-08/SetupWizard/scree… As Mike pointed out, we are trying to get to alpha ASAP so we can deliver much smaller TBB packages – without Vidalia. For that reason, some of the improvements that people suggested will be left out for now (e.g., automated probing for proxy or firewall settings). -- Mark Smith Pearl Crescent, LLC http://pearlcrescent.com/

9 12

Local onionoo cache
by David Fifield 13 May '13

13 May '13

Karsten, could I ask you to take a quick look at this code? https://trac.torproject.org/projects/tor/ticket/7549#comment:14 https://trac.torproject.org/projects/tor/attachment/ticket/7549/onionoo-que… It's a daemon that keeps a local cache of potential exit relays, sourced from onionoo. It listens on a local port and sends "EXIT" when asked about an IP address that is possibly an exit. The idea behind this code was to have a fast local database that we can rapidly query from the flash proxy facilitator, in order to prevent Tor users from being flash proxies themselves. Is this code the most straightforward way you can think to achieve the goal? Do you have any suggestions on the use of onionoo? I wonder if something like the daemon exists already. The code looks reasonable, though I would make some changes before merging it. I want to gauge whether detection of exits is worth the additional code. David Fifield

4 6

Tor Censorship Detector: Can I help?
by Sam Burnett 13 May '13

13 May '13

Hi, I'd like to help improve the Tor Censorship Detector. I've read some background material and think I understand the basics of George Danezis' detection algorithm [1, 2]. Is anyone still working on this? Two tickets from a year ago talk about experimenting with various detection algorithms and turning one of them into a standalone utility [3, 4]. Has anything happened since then? My background: I'm a graduate student at Georgia Tech studying network censorship circumvention and measurement. Although I've met Tor developers on various occasions, I haven't directly contributed to the project; I'd like to change that. Thanks! Sam [1] https://lists.torproject.org/pipermail/tor-dev/2011-September/002923.html [2] https://metrics.torproject.org/papers/detector-2011-08-11.pdf [3] https://trac.torproject.org/projects/tor/ticket/3718 [4] https://trac.torproject.org/projects/tor/ticket/4180

3 3

Re: [tor-dev] Iran
by monet＠tormail.org 10 May '13

10 May '13

Is any IP6 in Iran? IP6 is blocked too?

1 0