- tor-dev - lists.torproject.org

Pluggable transports meeting tomorrow (16:00 UTC Wednesday 18th of March 2015)
by Yawning Angel 17 Mar '15

17 Mar '15

(Trying to get these back onto a regular schedule now that dev-meeting madness is over.) Just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Plugg… -- Yawning Angel ps: UTC does not do daylight savings. Those of you that have had clocks change, please double check the time and let me know if we need to change the time.

1 0

tor not starting with NoNewPrivileges = yes (systemd)
by Nusenu 17 Mar '15

17 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I'm currently preparing/testing a systemd unit file (#14995) for debian (wheezy-backports/systemd 204) based on the one shipped by tor [1]. It does not work yet, and although the 'fix' would be easy - simply remove: NoNewPrivileges = yes I'd like to hear from you before removing such a security feature. Does tor require new privileges to work? It actually fails in two instances: 1) before actually starting the tor daemon (--verify-config): Process: 2844 ExecStartPre=/usr/bin/tor -f /etc/tor/torrc - --verify-config (code=exited, status=227/NO_NEW_PRIVILEGES) 2) and when actually starting the daemon thanks, Nusenu I'm testing with 0.2.5.10-1~d70.wheezy minimal test torrc used: User debian-tor DataDirectory /var/lib/tor Log debug file /var/log/tor/log [1] https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in#n25 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCE4hAAoJEFv7XvVCELh0AsMP/2DhEt+oLcSyN0w5pN6iyy2B O3WI+k4ZpC+OVKtRdQPcdmiCodo4So70ZGN3qEJKDTVLHW1YFn2p7z0a57OvYvkA SfQEy6yilQ1cUUMYUNj34WOdsq/tKDSmWQnJRvSUkdt1G2/WUJ14t0NRdR0KIzy0 bFQUYSkp2mnal8GpAldhx5q8P7zRlnf/fJC2gsQMJEEtPFwTGAl++cZ1mvuf00zk TsLo0L4BJ4EkAA4txJ8aihbYVZI0mJn2rWSc9OHVElNNiSYN2+d1k3bhCZHY/K2N yFnYY1lqoBcpmHakSOs2NqJx7arSMZY59oFR4Z9qBK+bpFQohzwOmV47Qfj8vahV CkDEIlh9OAYn59MahsBGJFMl/lSEVSAD60ZcTb3tveJEDSFtBJx9ey0P21MTlukh b+JUjc28UmNxLwHz/2bpe4+RZ0qKY2g+NnlbupNU+FUZGH9aiAxvpVKzFcxwvh6n wFiiRnQ8wWMZSMB5iOvltjt8jtxy2cvLrDypbsyEI28CdTuqAD+V0DrAn91Qyd2G aQwW+XkplwgiX8lVS8pno8P+EpAEoN1av8R2IVayN4zsp/IkgTff2W6GzTm4jQIB eL3vJz5OaK8q32wABNIMq7kaKs2O8VLbuxilZMDb0dmSozTQwNztpUsJFTiOZpbG yJllYQDwN3VuDBO9QXGY =osrb -----END PGP SIGNATURE-----

2 4

RAPTOR: Routing Attacks on Privacy in Tor
by Prateek Mittal 17 Mar '15

17 Mar '15

All, Our team at Princeton has been working on "Raptor: routing attacks on privacy in Tor". These attacks can be launched by Autonomous System (AS)-level adversaries, and exploit the dynamics of inter-domain routing. We show that by exploiting routing asymmetry, routing churn, and routing vulnerabilities (such as BGP hijacks and BGP interceptions), user anonymity can be compromised much more effectively than previously thought. We evaluated these attacks using historical BGP and Traceroute data, as well as by performing real-world attacks on the live-Tor network, without harming real Tor users. Our technical report is available at: http://arxiv.org/abs/1503.03940, feedback is most welcome. While all of our attacks have consequences for user anonymity, attacks based on BGP interceptions are particularly dangerous for the Tor network. These attacks allow an adversary to intercept Tor traffic "on demand", regardless of the adversary's network location. Our work demonstrates such an attack -- with success, on the live Tor network. We find that 90% of the Tor relays have a BGP prefix shorter than /24, enabling an adversary to advertise a more specific prefix for them, which is propagated *globally*. Countermeasures against interception attacks are challenging: we outline a number of ideas including advertising Tor relays with /24 prefixes, building frameworks to monitor the control plane and dataplane of Tor relays to detect such attacks (we have started to build such monitoring frameworks at Princeton), and in the long term -- aiming to speed up the deployment of secure inter-domain routing protocols in the Internet. Thanks, Prateek -- Prateek Mittal Assistant Professor Princeton University http://www.princeton.edu/~pmittal/

1 0

Syncing the Tor+TBB release schedules?
by Mike Perry 16 Mar '15

16 Mar '15

On #tor-dev on IRC, I noticed Nick and Mark discussing trying to sync the release schedules of Tor and TBB. I replied to Nick there with more info, but it may be lost in scrollback. So I'm restarting the discussion here. This email should give everyone on the tor-core side more info than they ever wanted to know about the Tor Browser release schedule. For Tor Browser, we are rather tightly bound to Mozilla's release schedule on two timescales: a 6 week point release cycle, as well as a 42 week Extended Support Release cycle. You can see this release schedule here: https://wiki.mozilla.org/RapidRelease/Calendar#Future_branch_dates. Note that schedule only lists the Rapid Releases, but there are Firefox 31-ESR point releases (with security fixes) on the same day as all Rapid Releases. This is where our 6 week cycle comes from for Tor Browser, and it is why we will always have a release on the same day as those Rapid Release dates. In terms of merge deadlines for our releases, Mozilla tags the all releases one week prior to the actual release date. This means we typically code freeze both TBB stable and alpha one week prior to release, and begin building off of their new tags at that point. This also means that the deadline for Tor Browser picking up a new Tor or PT version is also roughly 1 week prior to those release dates. The 42 week cycle comes from the Extended Support Release switch-over. Every 7 Rapid Releases, Mozilla creates a new Extended Support Release (ESR) series. We are currently on Firefox 31-ESR. The next ESR is 38-ESR. Note that the release calendar page lists Firefox 38 beta as due on March 31st, and Firefox 38 as due on May 12th. We then have 2 more rapid release cycles until Firefox 31-ESR is officially end of life. This means we have until August 11th to rebase all of our patches, audit and review Firefox 38, and write more patches for any issues we discover. So, how do these releases map to our upcoming TBB releases in terms of our versioning and stabilization? Well, our plan for 4.5-alpha is to freeze on March 26th, and then release TBB 4.5a5 on March 31st. We hope to declare 4.5 stable soon after that (~2 weeks). It seems by coincidence, Tor 0.2.6.x should be stable roughly around that time as well. The reason why we are releasing 4.5-stable out-of-cycle is to provide a 1 month grace period for people to still be able to run TBB 4.0 in case there are any catastrophes hiding in 4.5. After that (in mid-April), we will branch a new alpha series (5.0-alpha), which will target the next Firefox ESR release, based on Firefox 38. This means that from April until Aug 11th, the TBB team will be mostly focused on the switch to FF38-ESR (reviewing changes, updating patches, fixing tests, notifying Mozilla of patches they might like, etc). On https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor, I notice that we currently have Tor 0.2.7 scheduled to be stable by mid-Sept, which is slightly out of sync with a goal of shipping the FF38ESR-based Tor browser and Tor 0.2.7.x-stable together on August 11th. This may place us in the weird position of shipping a TBB 5.0-alpha with 0.2.7 and FF38 for most of the FF38ESR stabilization period (April-Aug 11), and then having to decide if we want to just roll the dice on 0.2.7, or roll back to 0.2.6. Obviously both options will carry some risk of instability. As fair warning, I am very likely to decide that it will be better to ship 0.2.7.x in TBB 5.0-stable on Aug 11th, as I suspect that the risk from things like PT compatibility and control port compatibility issues will actually make a rollback to 0.2.6 more risky on balance than sticking with 0.2.7.x. -- Mike Perry

3 7

Re: [tor-dev] Progress on hidserv-stats Metrics integration, request for code review
by Karsten Loesing 13 Mar '15

13 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Cc'ing tor-dev@, because why not.] On 11/03/15 19:13, Karsten Loesing wrote: > Please let me know if I can help *reduce* confusion somehow. :) Looking forward, hidden-service statistics are now available on Metrics: https://metrics.torproject.org/hidserv-data.html I also started making some very quick graphs here: https://people.torproject.org/~karsten/volatile/hidserv-stats-2015-03-11.pdf The question is, what graphs do we want on Metrics? How about: - Total hidden-service traffic in Mbit/s (per day, using weighted interquartile mean, like lower graph on page 1 of the PDF) - Unique .onion addresses (per day, using weighted interquartile mean, like upper graph on page 1 of the PDF) - Fraction of relays reporting hidden-service statistics (containing both dir-onions-seen and rend-relayed-cells, like page 3 of the PDF) Note that I left out "fraction of traffic", because we can't guarantee that our many assumptions we made for the blog post will hold in the future. Happy to be convinced otherwise. Also note that more is not necessarily better. All graphs we put on Metrics should be easy to comprehend for non-researchers and non-developers. If there's a graph that you care about but that not many other people would care about, it's easier to write a graphing script to plot what's in hidserv.csv rather than add yet one more thing to Metrics. By the way, I decided against using onion service terminology, because I wasn't sure when we were planning to switch. I'm not sure if Metrics should be one of the first Tor websites to switch, or whether people will just wonder what crazy Tor-unrelated stuff Metrics has statistics for. I don't feel strongly though. Thoughts? Thanks! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVAbKrAAoJEJD5dJfVqbCrRpcH/269XxlatdhSjiqlrIVxmfjU Yz9UnnrBToYJQ1As1o7KUG7NiW+vpq/qmsdNNxjogyEUr4EOPQVd6TDb/4+xjcDM HbiZRfrEu51KSDPiOYqZwFWcOoSOMtf34PiTyu+eo+xWsZ8fd+FCrnk5Qk9rDP7S RYKtHSV9RWY8G3RmDJHqOJNwbF76vxKVHVfQ2qY9ufHe3emS6eAkFzlg8KqRFrkv i1zhyXPNWUauW6mKfUWa/nCS7fae46xzx6J3oertvbKdBKtcNmyl1PqYgrCDTIUX pc4N68xyCJN+FNji/uI6mWCcW2FE059uGYDNpOMzJGeSovU0naPTrpmROtR7Mts= =P8oo -----END PGP SIGNATURE-----

3 4

Re: [tor-dev] Progress on hidserv-stats Metrics integration, request for code review
by Karsten Loesing 13 Mar '15

13 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/03/15 17:08, A. Johnson wrote: >> Looking forward, hidden-service statistics are now available on >> Metrics: >> >> https://metrics.torproject.org/hidserv-data.html > > Looks great! > >> - Total hidden-service traffic in Mbit/s (per day, using >> weighted interquartile mean, like lower graph on page 1 of the >> PDF) >> >> - Unique .onion addresses (per day, using weighted interquartile >> mean, like upper graph on page 1 of the PDF) > > These seem like a good idea. Great! I started with the second graph, because it seems least disputed: https://metrics.torproject.org/hidserv-dir-onions-seen.html >> - Fraction of relays reporting hidden-service statistics >> (containing both dir-onions-seen and rend-relayed-cells, like >> page 3 of the PDF) > > This is probably less interesting to most people, but it is > important to people serious about understanding the meaning of the > data. So I could take this or leave it. Agreed. I'll leave this graph out for the moment. >> Note that I left out "fraction of traffic", because we can't >> guarantee that our many assumptions we made for the blog post >> will hold in the future. Happy to be convinced otherwise. > > The calculation of client traffic fraction assumed that most > traffic from exit relays was in fact exit traffic. The validity of > that assumption may indeed change in the future, depending > especially on how the consensus position weights change. So I agree > that it is not a great idea to include a graph of this number on > the Metrics page. I wonder if we can simplify the calculation somehow, so that we don't have to worry (as much) that it will break in the future. Hmm. > The calculation of traffic fraction at relays only relied on (i) > rendezvous circuits being six hops (not a shaky assumption) and > (ii) that the Metrics numbers for total network traffic was > accurate (also seems like a good assumption). So it seems that we > could include this number, although it is the less interesting of > the two numbers. True. Let's keep this in mind as plan B. >> By the way, I decided against using onion service terminology, >> because I wasn't sure when we were planning to switch. I'm not >> sure if Metrics should be one of the first Tor websites to >> switch, or whether people will just wonder what crazy >> Tor-unrelated stuff Metrics has statistics for. I don't feel >> strongly though. Thoughts? > > You could use the new terminology, with a footnote on the page > explaining that "onion service" is the same as "hidden service". I think I'd rather want to wait until documentation on Tor's website and in tools is updated. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVAwHAAAoJEJD5dJfVqbCrdJsH/iUuCNMq/R/Yki015ZZ6i7+z OfszriSwUsO4MNuAX7E3yHHlbd5ZDnPJbN+H65wSIrFz2Tu8i1OopORu4EfJLukN 9zpS+SSR0ZoQk4BP8bw0447b46V6GsCy14TLnxUvGBvA1qaYwZM7JKH+RIDkztN/ b1aHf1IxkH92LzxNex/bAkxU6+ivIrRUIC/+/hVa9F2K9FTEbMh1T1WrS9TAukPZ kRW/wqk2wVXgZYV3Vur6bP+5gXOjvXiO5gpKzBv0wVlroCLgOI8idzF1JScQc2AA vEoBr9iFF7JBgtCtnyg6GZNcZvqTIb1/cQ1e2xdYJLluX5UAveNExxC96bCl8lo= =kE9g -----END PGP SIGNATURE-----

1 0

Summary of meek's costs, February 2015
by David Fifield 13 Mar '15

13 Mar '15

Here's the summary of meek's CDN fees for February 2015. Earlier reports: https://lists.torproject.org/pipermail/tor-dev/2014-August/007429.html https://lists.torproject.org/pipermail/tor-dev/2014-October/007576.html https://lists.torproject.org/pipermail/tor-dev/2014-November/007716.html https://lists.torproject.org/pipermail/tor-dev/2014-December/007916.html https://lists.torproject.org/pipermail/tor-dev/2015-January/008082.html https://lists.torproject.org/pipermail/tor-dev/2015-February/008235.html App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 November 2014 $224.67 + $362.60 + $0.00 = $587.27 December 2014 $326.81 + $417.31 + $0.00 = $744.12 January 2015 $464.37 + $669.02 + $0.00 = $1133.39 February 2015 $650.53 + $604.83 + $0.00 = $1255.36 -- total by CDN $1715.53 + $2191.74 + $0.00 = $3907.27 grand total My motivation behind making these reports is to provide transparency and to contribute to the body of scientific knowledge. I think it's useful to document these kinds of numbers, for the benefit of others who want to experiment with this kind of system. The number of simultaneous users was up a little bit in February relative to December, hovering around 1250. https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… The bill for Amazon actually went down last month, for the first time ever. Okay, that is partially because February is about 10% shorter than January. Actually, if you account for the shorter month, the bill is eerily almost exactly the same: $669.02 * 28/31 = $604.28 ≈ $604.83 (actual Feb. cost) == App Engine a.k.a. meek-google == Bandwidth was up about 30% and instance hours were up about 45%. At the end of February, I tried tweaking some performance parameters as an experiment to cause fewer instances to be created. This is to reduce costs, and also because I guess that extra instances don't really help much with performance in this case. The creation of instances is triggered by the application's response latency, which for us is usually caused by some temporary network issue, rather than a lack of CPU or something like that. We'll see next month whether it has an effect. Here is how the Google costs broke down: 4114 GB $492.71 3226 instance hours $157.82 Compared to the previous month: 2944 GB $353.31 2221 instance hours $111.06 https://globe.torproject.org/#/bridge/88F745840F47CE0C6A4FE61D827950B06F9E4… == Amazon a.k.a. meek-amazon == meek-amazon was pretty much the same as last month. I am thinking about disabling the public Amazon backend, just because it's a bit more expensive and I haven't been able to get free credits for it. And when I say "disabling," I mean just removing it as a default option in Tor Browser; it wouldn't just stop working immediately. My idea is that we could publish a guide on setting up your own Amazon CloudFront instance, if CloudFront is a backend that works for you. Asia Pacific (Singapore) 115M requests $138.07 1018 GB $147.04 Asia Pacific (Sydney) 76K requests $0.10 1 GB $0.06 Asia Pacific (Tokyo) 29M requests $34.26 193 GB $24.99 EU (Ireland) 111M requests $133.22 868 GB $68.23 South America (Sao Paulo) 2M requests $4.25 11 GB $2.61 US East (Northern Virginia) 30M requests $29.90 278 GB $22.12 -- total 363M requests $339.80 2369 GB $265.05 https://globe.torproject.org/#/bridge/3FD131B74D9A96190B1EE5D31E91757FADA1A… == Azure a.k.a. meek-azure == I haven't been able to get estimated costs out of Azure. I didn't get a reply to my request last month to be added to whatever plan lets you see usage data. I did, however, recover the bandwidth history for the meek-azure bridge from Onionoo, so we can estimate what the cost would be. If we estimate a traffic mix similar to that of meek-amazon, with 40% coming from North America and Europe, and 60% coming from elsewhere, then the costs would be: https://onionoo.torproject.org/bandwidth?fingerprint=AA033EEB61601B2B7312D8… 2014-09 47 GB $5.53 2014-10 298 GB $35.04 2014-11 500 GB $58.80 2014-12 512 GB $60.21 2015-01 638 GB $75.03 2015-02 614 GB $72.21 https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8… David Fifield

1 0

Two TOR questions
by John Lee 13 Mar '15

13 Mar '15

4 3

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