tor-dev

tor-dev@lists.torproject.org

3 participants
3584 discussions

What's the explanation for weekly cycles in user graphs?
by David Fifield 18 Mar '15

18 Mar '15

When you look at the user graphs, many of them show a weekly cycle. What's our explanation for why this occurs? I notice it strongly when I look at the graphs for the meek pluggable transport, where usage is high on weekdays and lower on weekends. The same thing happens in some per-country graphs. (In all these graphs, the light white vertical lines are Mondays.) https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… https://metrics.torproject.org/userstats-relay-country.html?graph=userstats… https://metrics.torproject.org/userstats-relay-country.html?graph=userstats… You can eyeball more examples in the omni-graph: https://people.torproject.org/~dcf/graphs/relays-all.pdf But it doesn't look like that everywhere. Here are graphs for obfs3 and the United States: https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… https://metrics.torproject.org/userstats-relay-country.html?graph=userstats… And there is perhaps even the opposite pattern, where there are small peaks on the weekends, like in Germany: https://metrics.torproject.org/userstats-relay-country.html?graph=userstats… Is there a usual story we tell to explain what's happening? A few hypotheses: * People use Tor at work to get their job done (work firewall blocks sites they need). * People use Tor at work to goof off. * People are relaxing and partying on the weekends, not sitting in front of a computer. * People don't have good Internet at home, so they use it more at work (and Tor use just correlates with Internet use). George Danezis's tech report on discovering censorship events describes the weekly patterns but doesn't offer a cause. https://research.torproject.org/techreports/detector-2011-09-09.pdf "The deployed model considers a time interval of seven (7) days to model connection rates... The key reason for a weekly model is our observation that some jurisdictions exhibit weekly patterns. A 'previous day' model would then raise alarms every time weekly patterns emerge" David Fifield

2 2

#15349 Symbol "str_tools" not defined "Tortoise and the Hare" tutorial's script.
by Lluís 18 Mar '15

18 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi everyone, I opened the ticket #15349 about a bug in the "Tortoise and the Hare" stem tutorial's script. I think I've found the solution to it and I attached the corrected script to the ticket. I hope it helps. May I expect some kind of feedback about the ticket ? Lluís -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCWEbAAoJEJOS0D3m/rNlQoIQAJUVd68wbcZ54BgFaDrI3/oc Bq2WsTTjaXfu1eoCQV445UEVgcSVGySZUjygAKaJ+i+QBQNIk+Nz7Xh/OLyvyHGq 38p5WCJHOBwT2bGjojdmEAF1g/wX3M0WZPAs3mErOTTUdVq6Iari7GSProVhBWeh KME4rZ9NqWIlaxE3jn/53bnAHdXqb8OWagPasei8KtMop3i3vlkmjuG/xdU2QGPJ bHFi2oGGVMPp10/v8t4vVVusH2JQYCxypxg1aXDOGFioFWgFEzzgXOg08XNsCK4J jy5t00yb5BjzaJEkjyowd1AxdqLEbwy7XhiHYb23DFurHezMaYjBxTj8jSllDeT7 cz+4Hpo0yAcozqENAwKYd7QQdO2XhvlWHq0Xg3YbfymKW23a3nu85u1+Y0kbiPJE pc3ZhOPxAFujmj6ob06AJsw6efDjm5kH9yPYRh02mDZtsuetttCXil/NSftFdh2i yOoJo4EO9mrWMoacoF4vFWiiBBD6zlybWTAVWJiFKaZu1/1TRHZwjX8E3jV5xXUd IMpLmuzviTYBfpWSm+llkKCGCrNdy1Uk2qa8uFBfOsXniOwMPKk6YDnAN6gcuTWy pxqsOzGvTNjpsYrXeGCa+aep3yesGDPSY5sLgOF3V1Nj9gtnyUq9s3WQsIr2rzbn a4VSB7j8RPjSlMc+nkXc =5Ebl -----END PGP SIGNATURE-----

1 0

#14995: adding multi-instance support to debian packages (patch)
by Nusenu 17 Mar '15

17 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Weasel, many relay operators run multiple tor instances to overcome certain limitations. Currently the official deb packages do not come with an easy configurable way to run multiple tor instances. I created a ticket [1] and wrote a patch [2] to add such a functionality to the debian package while preserving the current behavior. A similar enhancement got submited to the RPM packages and is now shipped in RPMs since tor 0.2.6.4-rc [3]. It would be great if you could find some time to review and comment on #14995 - before tor 0.2.6.x gets released. thanks! Nusenu [1] https://trac.torproject.org/projects/tor/ticket/14995 [2] https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian… [3] https://trac.torproject.org/projects/tor/ticket/14996 https://lists.torproject.org/pipermail/tor-relays/2015-March/006605.html -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVBuQFAAoJEFv7XvVCELh0hHcQAKmAHfmu4zlA3lwg+4IJCMgr cu77F8PkGTS4j9I5Sg3WjTg3xSPTwK3KOmWz3a5SOlQNLfo/LnzEB4owGg9Q7Q95 AdCMuh7zipsrZuENjv0gbbVRsv+hopimFQOypPj7pbi6+3tL/x0T4cStiUcx43No 7RnvIKpm1QDBNGhwwCWrQglH+T+h+XKb0JjaAS9zuP9FEAt2/JkEwmUAGScxnhF1 xFYR2i3EkKx7eX7Z4TE0wIDx+Q2UDr4/KcK3ZYbFEg24aKn75Iqs6HUOMOZB/JSY viJ2Y6q/M5j8zNcwSQ9herZDb0D6s0TYmvWf0XZnJAKeoKR7WgFuUvZuY35Ka/Y7 oHalTFgCTx5mw4CIvvMe0ybMQHTYdkb8CWOyWcC+F+LaH9TQ1yqlDi9zgZ5VWk29 nOwXQoiZNW1w3mJJzdqKuhsNAQytCcWMkWnBrDK+lCfN0WWWFxGlO75rTO7q9VuC 3VbmXcZJLhQquvfnHtqJOFheyIiWhuw+f+czJMvkmgdiQ4D346OlkBkePdpY9Ebs gI7W0Q5SAUiKWvRQKlvNav961ciYGWGckFsXL0lNxxHT2pN1Yz4+2EF32yBQ38hu aErK9Ouy973Qzy+ZhyDveOEoNvgGA2VyEXPK8ipfEFxP/ckdlcS3tw7AlcU78VT0 8zutjeDy+AoiazIrUCYj =OeBF -----END PGP SIGNATURE-----

2 4

0.2.7 triage meeting
by isabela 17 Mar '15

17 Mar '15

Hello people! As you might have noticed at our roadmap [0] we have the following task: * Initial ticket triage + schedule for 0.2.7(due by March 20th) At the last Core Tor weekly IRC meeting we asked people to add the label 0.2.7 to the work they want to see done for the release. The only guideline so far is to also look at other's roadmap and keep their needs in mind as you decide what should go on the next release. We plan to start triaging this at the end of the next weekly meeting (Wed 3/18) and will probably need another meeting to finish this initial ticket triage. I am trying to figure out when is a good time to have the 'second round' of triage and that is why I am sending this note. Please look at the poll and let us know when is a good time for you: http://doodle.com/3e9223rb3q7uffd9 Thanks, Isabela [0] https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor

2 2

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev