- tor-dev - lists.torproject.org

Renaming arm
by Kenneth Freeman 12 Mar '15

12 Mar '15

Surely Everyone Tors Here Although I think Argus a better descriptive name. Good luck backronyming THAT.

4 6

Preliminary Debian packages for meek
by Ximin Luo 11 Mar '15

11 Mar '15

Source package: https://mentors.debian.net/package/meek Binary packages: https://people.torproject.org/~infinity0/bin/ From the binaries, one should install both meek-client and xul-ext-meek-http-helper; the latter depends on xfvb and xauth. meek-client has been modified slightly to run meek-http-helper in a headless firefox using Xfvb(1), so that it works even when run as a system service. Example torrc: ~~~~ UseBridges 1 Bridge meek 0.0.2.0:1 url=https://meek-reflect.appspot.com/ front=www.google.com ClientTransportPlugin meek exec /usr/bin/meek-client-wrapper --log /var/log/tor/meek-client-wrapper.log --helper /usr/bin/meek-browser-helper -- /usr/bin/meek-client --log /var/log/tor/meek-client.log ~~~~ Also, to have meek-client-wrapper clean up child processes correctly one needs to apply the patch mentioned here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779608#20 After running `service tor restart`, you'll end up with something like this: $ sudo ls -1a /var/lib/tor/ . .. .cache cached-certs cached-descriptors cached-descriptors.new cached-microdesc-consensus cached-microdescs cached-microdescs.new .dbus Desktop .gconf .gnome2 .gnome2_private .lesshst lock .mozilla state This is not ideal but I don't know of a good way around it - suggestions welcome. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git

2 2

Update on Roadmaps for Core Tor, Hidden Services and Tor Obfuscation
by Isabela 11 Mar '15

11 Mar '15

Hello everyone. In Valencia dev meeting we did an exercise to help create a roadmap (1yr) for the different Tor projects and organizational work. I've collected those roadmaps and published them here: https://trac.torproject.org/projects/tor/wiki/org/roadmaps (I will be sending a similar email to the other dev and org teams as well. ) What I would like to ask from the folks in this list, and who collaborate with*Core Tor, Hidden Services and Tor Obfuscation (PT, BridgeDB etc), *is to look at the tables for March and April and fill up the empty cells for: * sponsor -> is the task related to a sponsor? (or could be) * who -> person(s) who the task should be assigned to * tickets -> ticket(s) related to the task (please create them if appropriate) * date -> estimation dates are always good :) nickm has already created tickets for Core Tor tasks (Thanks Nick!) Let me know if you have questions. Here are the tables I am talking about: * March and April for Core Tor: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor * March and April for Hidden Services: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/HS * March and April for Tor Obfuscation: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/TorObfuscation thanks everyone, Isabela

1 0

Suggestions for Hidden Services Statistics Project
by Gautham Nekkanti 11 Mar '15

11 Mar '15

Hi, I have already shared my project idea on a Simple analytics tool for Hidden service providers. I am looking for suggestions and input from users who have had experience in hosting hidden services. Obviously, there would all useful traffic related statistics. I'm looking for suggestions on what tor-specific statistics do you think would be helpful? As meejah suggested, we are thinking on including a few tor-specific statistics like 'How many times their onion descriptor was requested', 'No of bytes transferred through circuits', e.t.c. Thanks

2 1

Two protocols to measure relay-sensitive hidden-service statistics
by A. Johnson 10 Mar '15

10 Mar '15

Hello tor-dev, While helping design ways to publish statistics about hidden services in a privacy-preserving manner, it has become clear to me that certain statistics cannot be safely reported using the current method of having each relay collect and report measurements. I am going to describe a couple of simple protocols to handle this problem that I think should be implementable without much effort. I'd be happy to get feedback in particular about the security or ease-of-implementation of these protocols. Two HS statistics that we (i.e. people working on Sponsor R) are interested in collecting are: 1. The number of descriptor fetches received by a hidden-service directory (HSDir) 2. The number of client introduction requests at an introduction points (IPs) The privacy issue with #1 is that the set of HSDirs is (likely) unique to an HS, and so the number of descriptor fetches at its HSDirs could reveal the number of clients it had during a measurement period. Similarly, the privacy issue with #2 is that the set of IPs are (likely) unique to an HS, and so the number of client introductions at its IPs could reveal the number of client connections it received. A approach to solve this problem would be to anonymize the reported statistics. Doing so raises a couple of challenges, however: 1. Anonymous statistics should be authenticated as coming from some relay. Otherwise, statistics could be polluted by any malicious actor. 2. Statistical inference should be made robust to outliers. Without the relay identities, it will be difficult to detect and remove values that are incorrect, whether due to faulty measurement or malicious action by a relay. I propose some simple cryptographic techniques to privately collect the above statistics while handling the above challenges. I assume that there exists a set of Statistics Authorities (StatAuths), of which at least one must be honest for the protocol to be secure, but all of which can be "curious" (that is, we want to maintain privacy from them as well and allow their action to be completely public). The Directory Authorities could serve as StatAuths. A single server could as well, if you trust it to be honest- but-curious. If you have a trusted non-curious server, things become much simpler, of course: just have relays report their values to the server and then have it publish a global aggregate only. The AnonStats1 protocol to privately publish both statistics if we trust relays not to pollute the statistics (i.e. #2 is not a problem) is as follows: 1. Each StatAuth provides 2k partially-blind signatures on authentication tokens to each relay in a consensus during the measurement period. The blind part of a signed token is simply a random number chosen by the relay. The non-blind part of a token consists of the start time of the current measurement period. The 2k tokens will allow the relay to submit k values to the StatAuths. Note that we could avoid using partially-blind signatures by changing keys at the StatAuths every measurement period and then simply providing blind signatures on random numbers. 2. At the end of the measurement period, for each statistic, each relay uploads the following each on its own Tor circuit and accompanied by a unique token from each StatAuth: 1. The count 2. The ``statistical weight'' of the relay (1/(# HSDirs) for statistic #1 and the probability of selection as an IP for statistic #2) 3. The StatAuths verify that each uploaded value is accompanied by a unique token from each StatAuth that is valid for the current measurement period. To infer the global statistic from the anonymous per-relay statistic, the StatAuths add the counts, add the weights, and divide the former by the latter. The AnonStats1 protocol is vulnerable to a relay that publishes manipulated statistics (i.e. challenge #2). If this is a concern, the AnonStats2 protocol mitigates it by using a median statistic intead of a sum: 1. Relays are divided into b bins by consensus weight. The bins have exponentially-increasing length, and the rate of increase c is set such that the ith bin by increasing weights has at least r relays each of weight at least some minimum min_weight (say, r=500, min_weight=100). The first bin has weights in [0, min_weight), and the ith bin has weights in [min_weight*c^(i-2), min_weight*c^(i-1)). 2. Each StatAuth provides k partially-blind signatures on authentication tokens to each relay in a consensus during the measurement period. The blind part of a signed token is simply a random number chosen by the relay. The non-blind part of a token consists of the start time of the current measurement period and the bin containing the relay's consensus weight. 3. At the end of the measurement period, for each statistic, each relay divides each statistic by the relay's ``statistical weight'' (1/(# HSDirs) for statistic #1 and the probability of selection as an IP for statistic #2). The result is the relay's estimate of the global value of the statistic. The relay then uploads this value via a new Tor circuit, accompanied by a unique token from each StatAuth. 4. The StatAuths verify that each uploaded value is accompanied by a unique token from each StatAuth that is valid for the current measurement period and that contains the same relay-weight bin. To infer a final global statistic from the anonymous per-relay estimates, the StatAuths use the weighted median of the received estimates, where the weight of an estimates is taken to be the smallest value of its accompanying bin (i.e. the bin's left edge).

3 9

Using Traceroute for AS-Path prediction
by Simon Koch 10 Mar '15

10 Mar '15

I am a student at the saarland university and currently workin on my bachelor thesis concerning AS-path prediction using traceroute. I want to correlate open-source BGP data and corresponding traceroute measurements. In the end I want to argue whether or not traceroute can be valid tool for live as-path prediction based on the matching and representation of changes in the respective (AS-)routes over time. I already did a preliminary measurement during which I gathered 2 month worth of traceroute information to different tor-nodes and correlated them with the BGP data available at RIPE-RIS. It turned out, that routes predominantly matched and that a high percentage of bgp route changes were also present in traceroute routes. Though only a smaller number of traceroute route changes were present in bgp routes. This leads to the assumption that traceroute might be a good as-path measurement-tool, as it would be quite unlikely that BGP AS Paths would match AS paths derived from traceroute measurements if traceroute could not reliable measure them. This information was only inferred from only one measurement point, though. As this topic may also be of interrest to tor I was wondering if anyone had some opionions on the general idea or knew some papers/researcher which are on the same track. I already read: * Towards an Accurate AS-Level Traceroute Tool * Quantifying the Pitfalls of Traceroute in AS Connectivity * Inferring AS-level Internet Topology from Router-Level Path Traces * A Study on Traceroute Potential in Revealing the Internet AS-Level Topology * Mixing Biases: Structure Changes in the AS Topology Evolution but I have the nagging feeling that there should be more. Further I am looking for a way to establish more measurement points to ensure a diversity in the data collection. Those points have to be in AS-peers of either the route-views project (zebra routers) or RIPE-RIS so I can also access the corresponding MRT-Data. I figured that traceroute.org Looking Glass may provide a way of doing so, but I am afraid that the overlap of Looking Glass servers and public BGP-peers is very small. Any idea on how to establish diverse measurementpoints (maybe volunteers) would be greatly appreciated. Regards, Simon

3 2

Questions for the torflow developers
by Francois Valiquette 10 Mar '15

10 Mar '15

Hello, I am a master student in System Information Security in Canada and I am doing a project which will evaluate the security of the Tor Exit Nodes in a Tor user perspective. By reading the documentation of torflow, it is yet not clear to me, exactly which tests you are doing. One part of my project is to make a description of each possible attack an Exit Node can make and a description of a detection/mitigation mechanism for each of the attack but also I would like to implement one or more tests that have not been implemented by torflow. Here is a list of attacks that we think that a malicious Exit Node could do. The list is not complete, we will expand it. I would like to know, what type of attacks have you not tested and also, feel free to complete this list. -SSL and none SSL Sniffing (Session Hijacking, emails, web URL, IRC channel, FTP ) -Virus Injection (Linux, OSX, Windows, Android) -Misc Injection/Tampering: advertisements, JavaScript, etc -Pharming Attacks -DNS Rebinding -SSL MITM with CN -SSL MITM (revoked certificate, expired certificate and untrusted certificate) -SSL Downgrade attacks -SSL stripping -Dropping TLS connections -Spurious RST packets -Exploiting Bittorrent Tracker to reveal a user’s real IP Thank you for reading and sorry for the long post Frank

3 3

#9321 changes not included in tor-0.2.6.3-alpha changelog
by George Kadianakis 10 Mar '15

10 Mar '15

Hello Nick, I noticed that the 0.2.6.3 changelog does not contain the guardfraction blurb of #9321. I think this happened in c2312f4f5fbc37581180f53fb67edb70f3360104 where the bug9321 file was deleted but its contents were not added to the changelog. The text that is missing is: o Major features: - Introduce the Guardfraction feature which improves the load balancing of path selection towards guard nodes. Specifically, it aims to reduce the traffic gap that guard nodes experience when they first get the Guard flag. This is a required step if we want to increase the guard lifetime to 9 months or greater. Resolves ticket 9321. Maybe we should add it now even though the release has happened. Thanks!

2 1

Tor Project proposal for GSoC 2015
by Juro P. Doi 08 Mar '15

08 Mar '15

Hello, I would like to participate to the GSoC 2015 (my first one) and contribute to the Tor project. I am registered as timide on the OFTC IRC network. I am currently student in master of computer science, and working with LibFTE for a school project. Actually, fteproxy can be used as a Tor bridge in order to hide a Tor connection. To use this type of transport, one have to know the address of a remote fte proxy server or use an hardcoded one. I would like to improve the use of fteproxy in order that a client could use his own remote server or at the opposite could ask for one. The main idea is that server nodes announce themselves to a distributed service that clients could query. I already had some mail exchanges with the maintainer of the FTE tools, who advised me to post my proposal to the mailing list. It can be done at two different points: 1. into fteproxy so that it's Tor independant and any service that use fteproxy could benefit of it (as Tor) 2. into Tor so that all type of bridges could be shared Anouncements should be done over multiple protocols an queried with fallback by the clients. These methods could be over services known by hardcoded IP/URL or set by the user. Types of services could be: 1. services like https://gitweb.torproject.org/bridgedb.git 2. IRC 3. mail etc. What do you think about it? Thanks. Juro P. Doi

3 2

OONI weekly dev meeting today Monday 9th of March 18:00 UTC
by Arturo Filastò 08 Mar '15

08 Mar '15

Hello Oonitarians, As discussed during the last meeting we did not gather this week because of the OpenITP festival. It was a very fruitful and interesting event, that we should update people that could not attend about. We shall therefore gather at the usual 18:00 UTC (19:00 CET, 13:00 EST, 10:00 PST) on the #ooni channel on irc.oftc.net. See you soon! ~ Arturo

1 0