- tor-dev - lists.torproject.org

Otter Buoyant Meeting Today - Delay
by Kelley Misata 31 Dec '13

31 Dec '13

Team - Today's meeting of the Otter Buoyant project needs to be postponed until next Tuesday, 1/7. My laptop is having problems and I will be offline this afternoon to repair it. (hopefully) See you all on IRC next Tuesday 1/7 - 3:30 pm (EST) - IRC #tor-dev. Happy New Years! Kelley -- *Kelley Misata* *Outreach and Communications* *The Tor Project* *www.torproject.org <http://www.torproject.org>*

1 0

Fwd: [guardian-dev] Building OpenSSL and Xtables for Orbot
by Nathan Freitas 28 Dec '13

28 Dec '13

-------- Original Message -------- Subject: [guardian-dev] Building OpenSSL and Xtables for Orbot Date: Sat, 28 Dec 2013 09:28:57 -0500 From: Nathan of Guardian <nathan(a)guardianproject.info> To: Guardian Dev <guardian-dev(a)lists.mayfirst.org> For a long time, building an up-to-date OpenSSL and iptables binary was a challenge for apps like Orbot which need it. Figuring out all the various flags and patches necessary was quite tricky, and the version bundles in the AOSP code were quite out of date. I am happy to say that both through my own persistence, recent patches by a few others, and improvements in the Android NDK toolchain, we can down build the latest OpenSSL and XTables/Iptables code from the original, direct git source. This means we have all the latest ciphers for Tor to use in order to better obscure traffic, and we have a bundled xtables binary in Orbot that can handle all of the transproxying rules we need, no matter what the built-in rooted firmware provides. You can find the updates build instructions in the Orbot external Makefile here: https://gitweb.torproject.org/n8fr8/orbot.git/blob/HEAD:/external/Makefile We will have beta of the new release, based on Tor 0.2.4.20 shortly. +n _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpr… You are subscribed as: nathan(a)guardianproject.info

1 0

Does TLS round-trip optimization apply do Tor?
by Fabio Pietrosanti (naif) 24 Dec '13

24 Dec '13

Hi, i've been reading the article "Optimizing NGIX TLS time for first byte" below: http://www.igvita.com/2013/12/16/optimizing-nginx-tls-time-to-first-byte I've been thinking whenever that kind of optimization does apply also to Tor or not? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org

5 4

[Question to sysadmins and HS operators:] How should Hidden Services scale?
by George Kadianakis 24 Dec '13

24 Dec '13

Hello people, you might have noticed that there is a redesign of hidden services going on. For a while we've been told that "hidden services don't scale" and "there is a max number of clients that a hidden service can handle" so we decided to also consider hidden service scalability as part of the upcoming redesign. Unfortunately, we are not experienced in maintaining busy hidden services so we need some help here. For example, a load balancing technique that hidden services are missing is DNS round-robin; that is, something that load balances on the IP layer (you send some clients to one IP and the rest to another IP). To do the equivalent in hidden services you have to do the load distribution in the Introduction Point layer. Some people have been thinking about this: https://lists.torproject.org/pipermail/tor-dev/2013-October/005556.html https://lists.torproject.org/pipermail/tor-dev/2013-October/005674.html Unfortunately, the above designs are not trivial to implement. They require the hidden service peers to communicate with each other so that they can generate and recycle keys, and it also puts Introduction Points in a position where they can find out the status or number of hidden service peers. For this reason we started wondering whether DNS-round-robin-like scalability is actually worth such trouble. AFAIK most big websites use DNS round-robin, but is it necessary? What about application-layer solutions like HAProxy? Do application-layer load balancing solutions exist for other (stateful) protocols (IRC, XMPP, etc.)? What should we do to make Hidden Services scale to a large number of clients? Also, is "scalability" the correct phrase here? Should we replace it with a combination of "load balancing", "high availability", or something else? [I sent this mail twice because the first did not get posted in tor-dev.]

3 5

OnionMail 1.0.48B is Out.
by Liste 22 Dec '13

22 Dec '13

OnionMail 1.0.48B is now Ready. http://onionmail.onfo Now OnionMail can use GPG (We are upgrading some OnionMail Servers). The source code is on github: https://github.com/onionmail/onionmail If you don't want to connect only via tor, yo ca use an hybrid solution: The NTU LocalProxy https://github.com/onionmail/ntu It can hide more hiddenservices.

1 0

Re: [tor-dev] Statistics on fraction of connections used uni-/bidirectionally
by Florian Tschorsch 22 Dec '13

22 Dec '13

Hi Karsten, we still believe that the statistics are useful. However we also agree with Rob that since more and more relays report data the scatter plot becomes confusing. I think some kind of aggregation would be helpful. In one of our previous papers we assessed the performance impact of simultaneous TCP connections in overlay networks [1]. There we found that the occurring performance degradation is hard(er) to solve when connections are used bidirectionally -- which is the motivation for these statistics. From the current results I would presume that this is the case in Tor most of the time. In Future developments the statistics could become helpful. Cheers, Florian. [1] D. Marks, F. Tschorsch, and B. Scheuermann, "Unleashing Tor, BitTorrent Co.: How to relieve TCP deficiencies in overlays," in 35th IEEE Conference on Local Computer Networks (LCN'10), 2010, pp. 320–323. On 16/12/13 05:34, Rob Jansen wrote: > Hey Karsten, > > I think the statistics could be useful, though I don't currently utilize them. I think the current presentation is somewhat confusing. Perhaps we can try to brainstorm some alternative ways to present the data if the decision is that we should keep it around. > > Best, > Rob > > On Dec 9, 2013, at 12:43 PM, Karsten Loesing wrote: > >> Björn, Florian, >> >> a few years back (in 2010, to be precise) we added statistics to >> little-t-tor reporting what fraction of connections is used >> uni-/bidirectionally. Quoting dir-spec.txt: >> >> "conn-bi-direct" YYYY-MM-DD HH:MM:SS (NSEC s) BELOW,READ,WRITE,BOTH NL >> [At most once] >> >> Number of connections, split into 10-second intervals, that are >> used uni-directionally or bi-directionally as observed in the NSEC >> seconds (usually 86400 seconds) before YYYY-MM-DD HH:MM:SS. Every >> 10 seconds, we determine for every connection whether we read and >> wrote less than a threshold of 20 KiB (BELOW), read at least 10 >> times more than we wrote (READ), wrote at least 10 times more than >> we read (WRITE), or read and wrote more than the threshold, but >> not 10 times more in either direction (BOTH). After classifying a >> connection, read and write counters are reset for the next >> 10-second interval. >> >> These statistics are disabled by default, but when they are enabled, >> relays publish them in their extra-info descriptors. And quite a few >> relays do that. Here's a (bad) visualization (that used to be slightly >> less bad when fewer relays published these statistics): >> >> https://metrics.torproject.org/performance.html#connbidirect >> >> Here's the question: Is there still value in having these statistics? I >> recall that they were useful in 2010, but will that still be the case in >> 2013? >> >> If the answer is "yes", never mind. >> >> If the answer is "no", I'd create a ticket and submit a patch to remove >> code parts from little-t-tor, and I'd remove the not-really-useful graph >> from the metrics website. >> >> Cc'ing Rob, Aaron, and Roger as the people who typically have an >> interest in these kinds of statistics. If other tor-dev@ people have an >> opinion on this, please raise your voice! >> >> All the best, >> Karsten >

3 5

Trivial patch: avoid redundant calls to ENGINE_register_all_complete
by coderman 19 Dec '13

19 Dec '13

hello all, Nick, per the other thread in tor-talk about RDRAND, this is the minor fix for OpenSSL 1.0.1+ mentioned. i don't know that this is useful, and i am still giving the engine code a thorough review per Nick's other feedback: "Above all, do not assume that you understand how OpenSSL works until you have investigated with a debugger, the source code, and a pot of coffee." :) best regards, --- diff --git a/src/common/crypto.c b/src/common/crypto.c index 5afb98e..7c02ea4 100644 --- a/src/common/crypto.c +++ b/src/common/crypto.c @@ -282,7 +282,10 @@ crypto_global_init(int useAccel, const char *accelName, const char *accelDir) log_info(LD_CRYPTO, "Initializing OpenSSL engine support."); ENGINE_load_builtin_engines(); - ENGINE_register_all_complete(); + /* OpenSSL 1.0.1 and newer register complete when engines loaded. */ + if (SSLeay() < OPENSSL_V_SERIES(1,0,1)) { + ENGINE_register_all_complete(); + } if (accelName) { if (accelDir) {

2 3

Tor Metrics project - past, present, future
by Karsten Loesing 19 Dec '13

19 Dec '13

Dear devs, you probably know the Tor Metrics project with its most visible part, the metrics website [0]. The metrics website and the less visible parts around it have grown organically since 2009. I'm maintaining the code behind most of these parts, which is why I'm periodically trying to bring order into the chaos. Sometimes this means removing parts which are mostly unused or require too many resources, and removing working parts typically leads to sad faces. But sometimes I'm also adding new parts which has the potential of turning sad faces into happy faces again. When I talked to Tom on Thursday, he suggested that I should take a step back and explain here what metrics is for and what it's not for, and list the things that are great, the things that can go, and the things we might like in the future. Great idea, let me do that! Before I start, may I call your attention to exhibit A: https://metrics.torproject.org/tools.html This is a diagram showing all the different metrics parts and how they are connected. Really, please take a quick look at it, because I'm going to refer to the diagram below. So, *what* is metrics for? Perhaps it's easier to answer this question by saying *who* metrics is for: 1. For the researchers! The metrics project archives Tor network data, that is safe to be archived, and provides it to anyone on a public website [1, 2]. This is a valuable resource for researchers who are trying to back their research with actual data about the deployed Tor network. (Green parts in the diagram.) 2. For the community! The metrics website contains all kinds of statistics showing how the Tor network grew over time [3, 4], including details about relays, bridges, and clients as far as user privacy is not at risk. Focus is on the Tor network as a whole, from 2007 until today. (Purple parts in the diagram.) 3. For the operators! Onionoo [5] processes Tor network data and provides it in a convenient format for web applications [6, 7, 8] designed for relay or bridge operators, people helping to debug the Tor network, and more generally Tor users. Focus is on single relays or bridges right now or in the very recent past. (Orange part in the diagram.) And what is metrics *not* for? If you take another look at exhibit A, I'll explain three parts which I think are either not used anymore or require too many resources. If people think we really need to keep any of these parts, I'd like to know: 1. We added statistics on uni-/bidirectional connection usage a few years back. I think these statistics were useful for researchers at the time, but I haven't heard from anybody using them recently. We should remove them from little-t-tor and from metrics [9]. (Part of performance.html in the diagram.) 2. We introduced the notion of a fast exit for sponsor J, and we added graphs showing how many of these fast exits or almost fast exits are running in the Tor network. The sponsor contract ended, and the notion is too specific to be useful for anything else. We should remove the graphs. (fast-exits.html in the diagram.) 3. The relay-search service can find any relay that was running since 2007. This is certainly useful for debugging the Tor network, but it requires us to keep a full database of relays which doesn't scale anymore [10]. (relay-search.html in the diagram.) Last, but certainly not least, I have a couple of things in mind that we might like in the *future*. It would be good to know which of these things sound interesting to others, so I can direct my time on the most popular features first: 1. Start archiving microdescriptors and microdescriptor consensuses (#2785). While both descriptor types can be derived from server descriptors and unflavored consensuses, archiving the originals would be more convenient for researchers and developers. (Green parts in the diagram.) 2. Resume to add country codes and maybe AS numbers to sanitized bridge descriptors. We stopped resolving bridge IP addresses to country codes, because it's difficult to do that in a reproducible way with monthly changing GeoIP databases. But having country and maybe AS information would for sure be useful. (Green parts in the diagram.) 3. Keep contact lines in sanitized bridge descriptors (as discussed in #9854). Having contact lines of bridge operators would allow more people to contact them in case of problems, and it would allow bridge operators to find their bridge more easily in services like Atlas [6] or Globe [8]. (Green parts in the diagram.) 4. Make graph on the number of running obfsbridges (#9187). Bridges report which pluggable transports they support in their extra-info descriptors, and it's not trivial to extract this information and count how many bridges per transport are running at a given time. But it's also not terribly difficult. (Purple parts in the diagram.) 5. Re-enable relays-by-country graph on the metrics website (#8127). This is difficult for similar reasons as 2. (Purple parts in the diagram.) 6. Make bridges-by-country graph for the metrics website. Similar to 5, depends on 2. (Purple parts in the diagram.) 7. Include votes in Onionoo (#9778). Votes contain some interesting information about relays, like missing or extra relay flags, or measured bandwidth. The main problem would be potential performance issues. (Orange part in the diagram.) 8. Provide per-bridge usage statistics in Onionoo (#10331). We could tell bridge operators some estimates on the number of clients connecting to their bridge by country, transport, or IP version. Maybe this encourages bridge operators to run more bridges, in particular if they can show their social circle how their bridge helps actual people in the world. (Orange part in the diagram.) 9. Provide relay comparison metrics in Onionoo. We could define some simple metrics on the usefulness of a relay, like provided bandwidth or uptime, in comparison to other relays. A possible statement from these metrics could be: "your relay provides more bandwidth than 95% of relays in the network." Similar to 8. If Atlas [6] or Globe [8] or a yet-to-be-written Facebook application or a also-yet-to-be-written Twitter integration into Tor Weather (#10372) tell the world how successful someone's running Tor relays, maybe that encourages others to run relays, too. We could even invent a points system for running relays, with additional points for running exits, if that makes the Tor network better. Probably needs input from a community coordinator person. (Orange part in the diagram.) Whee, that was a comprehensive discourse on the past, present, and future of the metrics project. Thanks for reading! Feedback much appreciated! All the best, Karsten [0] https://metrics.torproject.org/ [1] https://metrics.torproject.org/data.html [2] https://metrics.torproject.org/formats.html [3] https://metrics.torproject.org/network.html [4] https://metrics.torproject.org/users.html [5] https://onionoo.torproject.org/ [6] https://atlas.torproject.org/ [7] https://compass.torproject.org/ [8] https://globe.torproject.org/ [9] https://lists.torproject.org/pipermail/tor-dev/2013-December/005919.html [10] https://lists.torproject.org/pipermail/tor-talk/2013-December/031310.html

2 2

InjectSOCKS: 2nd try
by tor＠herr-der-mails.de 17 Dec '13

17 Dec '13

Hello, I've first sent this e-mail to help(a)rt.torproject.org and the answer was to send a copy of it to the "tor-dev mailing list". So that's what I do: I just wanted to let you know that I've created a small new tool for Windows called InjectSOCKS that can force other Windows software to do TCP connections via SOCKS. This way software not supporting SOCKS can be used together with Tor. You don't need any additional HTTP proxy or other proxies. As an example it works for passive FTP, too. Additionally it handles the DNS requests of that other software in a way that while creating the SOCKS connection, Tor gets the textual address - so the exit node can resolve it (which is the way favored by the Tor developers). This way Tor hidden services work as well. And it works per Windows process, so it doesn't influence the whole operating system. In case you're interested in my software, I've put it on sourceforge to make it open source: http://sourceforge.net/projects/injectsocks The tool is far from being perfect yet, but I think some of the ideas are interesting. By the way, I've also created DNS2SOCKS, which is already listed on Tor's Wiki: http://sourceforge.net/projects/dns2socks It seems like several people like it, so I hope that some people will also like InjectSOCKS. Regards, ghostmaker

3 6

Gitian Build Failure (pt branch only?)
by Kevin P Dyer 17 Dec '13

17 Dec '13

Hi Mike/dcf1, Building the pt branch [1] of tor-browser-bundle on Ubuntu 13.04, 64-bit resulted in the following error: <<< ./bin/gbuild:21:in `system!': failed to run on-target setarch i386 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError) from ./bin/gbuild:121:in `build_one_configuration' from ./bin/gbuild:223 from ./bin/gbuild:218:in `each' from ./bin/gbuild:218 from ./bin/gbuild:216:in `each' from ./bin/gbuild:216 make: *** [build] Error 1 >>> dcf1 suggested that I downgrade to the 3.2.0 kernel. This wasn't (obviously) supported in 13.04, so I decided to downgrade my system to 12.04. On a clean 12.04, 64-bit, install I got the same issue. Then, the following resolved the problem for me: <<< $ sudo apt-get remove linux-image-3.8.0-29-generic linux-image-generic-lts-quantal linux-image-generic-lts-raring $ sudo apt-get --reinstall install linux-image-generic >>> I did not encounter this problem when building [2] last week. When the failure occurs, var/build.log contains the "invalid instruction suffix" errors as reported in [3]. -Kevin [1] https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git [2] https://gitweb.torproject.org/builders/tor-browser-bundle.git [3] https://github.com/cloudmatrix/myppy/issues/7

4 7