March 2015 - tor-dev - lists.torproject.org

Producing automated screencasts for Tor Browser
by Karsten Loesing 19 Mar '15

19 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, we're making some medium-term plans to produce automated screencasts that explain how to download, verify, and run Tor Browser on Windows, Mac OS X, and Linux, localized to at least half a dozen languages. The focus here is really on *automated*. Whenever there's a new Tor Browser version, we'd like to minimize manual steps for creating new screencasts to the absolute minimum. Here's our plan, and we'd appreciate your feedback on this: 1. Set up three systems (Windows, Mac OS X, and Linux) either as virtual machines, using VirtualBox or VMware Fusion, or on a dedicated triple-boot Mac Mini. 2. Install Sikuli (http://www.sikuli.org/; thanks for Lunar for the suggestion!) either directly on these machines or on the virtual machine host or on a separate host in the same network. 3. Write a Sikuli script for each operating system and language, probably re-using large parts, to make all the necessary steps to download, verify, and run Tor Browser. This script may include steps for preparing the system by changing its language and for cleaning up afterwards. Ideally, this script can easily be maintained whenever Tor Browser changes. 4. Record audio snippets in the various language that explain the steps that will later be performed in the screencast. Either include these as part of the Sikuli script, or put them together separately and add them to the recording later. 5. Start a screen recorder and run the Sikuli script for all three systems and all supported languages. 6. Post-process the recording by cutting the video, attaching the audio, and possibly adding text slides at beginning and end; hopefully using scripts. Again, the goal is to keep the overhead for recording a new set of screencasts as low as possible. If it takes days to do this, nobody will do it, and we'll soon have outdated videos. What do you think about this plan? And do you have specific suggestions for the single steps? Thanks! Cheers, Karsten and Sherief -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVCp9HAAoJEJD5dJfVqbCrfTEH/2oTPvEYIZDys42MeKXmQFA9 bmVMky5sCO6/sOAx8BIVdUXF1b1m8mxPev5X2SarYCyNaZOkbtCOLyLzrFjUii0e aH7cjc6QFm31TX5oJ10O7/7Of13q4l0jYY2j0KDmzbFrNndK9t9W+nh4/xSiTdEh a3IzVnOVu4c1nE4xwCSxwqaia2xi5N8fUuZPN4ttGGVctp4ucglUwTCZodfqNUMK Jiq4UO+ZeGvPaRGPLK8sxCfnR5DrZF5i3v4YhYy5d1g0yGDNFHv61zP1PQHx3BCG 47ne5o+FDsxLxDe1w4/l7i4HvdPHP7XovkR4yckYs/6e4462QUfBxVcwIm9p6rk= =E8Kf -----END PGP SIGNATURE-----

3 2

Wide block cipher experiment.
by Yawning Angel 19 Mar '15

19 Mar '15

Hello, Nickm mentioned to me that he was curious as to how LIONESS performs these days (See #5460) with modern cryptographic primitives. I've conveyed the results to several people, but I'm also sending them here for posterity. Code used: https://github.com/yawning/lioness (May be incorrect, don't use for anything other than benchmarking. Numbers taken with a previous version of the code without the initial memcpy, that was added later so that the code in git could be used by the extremely brave for other things.) All measurements taked on an i5-4250U, so the usual caveats about turboboost and hyperthreading apply. Baseline (from tests/bench, AES-NI enabled): ===== cell_ops ===== Inbound cells: 231.33 ns per cell. (0.45 ns per byte of payload) Outbound cells: 224.39 ns per cell. (0.44 ns per byte of payload) (Note: Outbound with AES-NI disabled is ~3.0 ns per byte) LIONESS (BLAKE2b/ChaCha, 509 byte block size): * ChaCha20: * Ted Krovetz's AVX2-ed ChaCha20/Ref AVX BLAKE2b: ~6.6 ns/byte (~143 MiB/s) * AVX2ed-ed ChaCha20, Andrew Moon's AVX2-ed Blake2b: ~5.0 ns/byte (~190 MiB/s) * ChaCha12: * Ted Krovetz's AVX2-ed ChaCha12/Ref AVX BLAKE2b: ~6.1 ns/byte (~156 MiB/s) * AVX2ed-ed ChaCha12, Andrew Moon's AVX2-ed Blake2b: ~4.4 ns/byte (~213 MiB/s) * ChaCha8: (Yolo swag 420 blaze it) * Ted Krovetz's AVX2-ed ChaCha8/Ref AVX BLAKE2b: ~5.8 ns/byte (~164 MiB/s) * AVX2ed-ed ChaCha12, Andrew Moon's AVX2-ed Blake2b: ~4.1 ns/byte (~232 MiB/s) NB: Using Andrew Moon's Blake2b isn't in git, because the way I tested it was kind of kludgey. Profiler output: 64.04% lioness_test_av lioness_test_avx2 [.] blake2b_compress 22.43% lioness_test_av lioness_test_avx2 [.] chacha_stream_xor 6.60% lioness_test_av lioness_test_avx2 [.] blake2b_init_key 2.72% lioness_test_av lioness_test_avx2 [.] blake2b 2.41% lioness_test_av libc-2.21.so [.] __memcpy_avx_unaligned 1.07% lioness_test_av lioness_test_avx2 [.] lioness_encrypt_block Ted Krovetz's ChaCha implementation isn't quite the fastest out there, but it doesn't lag massively behind Andrew Moon's. Benchmarks on the same hardware from Andrew Moon's chacha-opt/blake2b-opt are: BLAKE2b: 576 byte(s): avx2, 1468.00 cycles per call, 2.5486 cycles/byte avx, 1674.00 cycles per call, 2.9062 cycles/byte x86, 2020.00 cycles per call, 3.5069 cycles/byte generic/64, 2638.00 cycles per call, 4.5799 cycles/byte ChaCha20: 576 byte(s): avx2, 694.00 cycles per call, 1.2049 cycles/byte avx, 1104.00 cycles per call, 1.9167 cycles/byte ssse3, 1112.00 cycles per call, 1.9306 cycles/byte sse2, 1376.00 cycles per call, 2.3889 cycles/byte x86, 2528.00 cycles per call, 4.3889 cycles/byte generic, 3200.00 cycles per call, 5.5556 cycles/byte I don't think using CTR-AES (with AES-NI) in a LIONESS construct is going to be that big of a win, at least on my hardware, and the sort of performance I'm seeing feels too much of a performance hit to me. Regards, -- Yawning Angel

1 0

Fwd: Intent to Ship: 3rd Party Install Tracking
by Nathan Freitas 19 Mar '15

19 Mar '15

Another thing to remove/disable from Tor Browser "Mini" (aka Orfox)... ----- Original message ----- From: Mark Finkle <mfinkle(a)mozilla.com> To: "mobile-firefox-dev(a)mozilla.org" <mobile-firefox-dev(a)mozilla.org>, "dev-platform" <dev-platform(a)lists.mozilla.org> Subject: Intent to Ship: 3rd Party Install Tracking Date: Wed, 18 Mar 2015 14:28:57 -0400 We wanted to start some transparency around a new integration coming to Firefox on Mobile [1]. We are planning to integrate a 3rd party install tracking SDK from a company called Adjust [2] which will send data, possibly device identity data [3], to a 3rd party server. We don't do this very much at Mozilla so we wanted to be proactive about messaging. There are good reasons for wanting to collect the data. Our marketing and growth goals for 2015 will require spending non-trivial amounts of money. The data will help us spend the money responsibly and efficiently. Advertising metrics on Mobile is not as simple as some Desktop systems. On Desktop, we can do most of this using the download links on our web pages. Mobile installs come from App Stores, and it's harder to integrate into those system. This is Mozilla, so we are worried about integrating the SDK from a privacy and tracking concern. The goal is to limit the data to non-PII sensitive information and we'll only allow the data to be pushed once, on an INSTALL_REFERRER intent [4] sent when Firefox for Android is first run after being installed from the Play Store, and only when the install is coming from an advertising campaign. No other data will be sent at any other time. Normal installs from the Play Store would not have any data collected. We still need to audit the open source SDK to see exactly what data is sent and how it's collected. We also have started doing a security/privacy/legal audit of the vendor and their collection/storage practices. Just a note, this is not the first attempt to add such 3rd party data collection to Firefox on Mobile. The other attempts did not happen because we found flaws in the systems or the system failed to meet our concerns about privacy. The proposed system seems to have a decent chance of passing our audits around privacy and security, so it's time to open the discussion to a wider audience. Here are some other notes about the Adjust system: * This is an open source SDK, fully transparent, based in Germany, widely adopted and regarded, beholden to the strictest EU privacy standards. * We will collect the absolute minimum data, once, to measure for install. We’ll know exactly what data is being passed. * We’re paying for the SDK and service, which is good because the vendor's model is not based on monetizing our data in aggregate to develop behavioral segments for other advertisers. * This will allow real-time optimization of marketing dollars, much like virtually all major mobile apps do, and much like we have already been able to do on paid marketing desktop for quite some time * We likely use this system until we can figure out how to do it by ourselves, in house. Until then, we need to be pragmatic. This is just a heads up email. We want the effort to be open and transparent. Questions and comments welcome. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1143888 [2] https://github.com/adjust/android_sdk [3] The SDK requires the use of the Google Advertising ID to uniquely track the device [4] https://github.com/adjust/android_sdk/blob/master/doc/referrer.md _______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev(a)mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev -- Nathan of Guardian nathan(a)guardianproject.info

1 0

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 18 Mar '15

18 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 18 Mar '15

18 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 18 Mar '15

18 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 18 Mar '15

18 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