- tor-dev - lists.torproject.org

Directory Server Consensus Status Flag
by Matthew Finkel 21 Mar '15

21 Mar '15

Hi all, I'd like some opinions. Currently authorities give relays the V2Dir if they are useful directory servers. Clients don't actually care about this flag in any way, but it's a useful visual indicator. With proposal 237 (All relays are directory servers) and #12538 as its implementation, the current plan is to continue using the V2Dir flag, but now clients will actually care if a relay has the V2Dir flag and choose directory servers based on it. Tickets #11103 and #1338 actually wanted to get rid of the V2Dir flag, for good reasons. If we're going to rename the flag, we should do it before #12538 is merged, and probably make the change in the same branch. The V2Dir flag needlessly specifies an unuseful protocol version. #1338 suggested switching to a V3Dir flag, but it was decided this was not such a good idea. Proposal 185 chose a "DirCache" Consensus flag. I think either "DirServer" or "DirCache" are good choices for this, but DirServer is more in line with the wording used in Prop 237. Are there any objections to changing the name of the flag? (There will be another email in a few minutes with an updated version of prop 237.) Thanks! Matt

1 0

Call for a big fast bridge (to be the meek backend)
by David Fifield 21 Mar '15

21 Mar '15

The meek pluggable transport is currently running on the bridge I run, which also happens to be the backend bridge for flash proxy. I'd like to move it to a fast relay run by an experienced operator. I want to do this both to diffuse trust, so that I don't run all the infrastructure, and because my bridge is not especially fast and I'm not especially adept at performance tuning. All you will need to do is run the meek-server program, add some lines to your torrc, and update the software when I ask you to. The more CPU, memory, and bandwidth you have, the better, though at this point usage is low enough that you won't even notice it if you are already running a fast relay. I think it will help if your bridge is located in the U.S., because that reduces latency from Google App Engine. The meek-server plugin is basically just a little web server: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/meek… Since meek works differently than obfs3, for example, it doesn't help us to have hundreds of medium-fast bridges. We need one (or maybe two or three) big fat fast relays, because all the traffic that is bounced through App Engine or Amazon will be pointed at it. My PGP key is at https://www.bamsoftware.com/david/david.asc if you want to talk about it. David Fifield

6 11

Re: [tor-dev] Fwd: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!
by Nathan Freitas 20 Mar '15

20 Mar '15

On Fri, Mar 20, 2015, at 04:05 AM, isis wrote: > Nathan Freitas transcribed 0.8K bytes: > > On Thu, Mar 19, 2015, at 06:58 PM, David Fifield wrote: > > > What would it take to get some screenshots that show how to turn on > > > pluggable transports? I would like to add a guide to > > > https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart and > > > instructions to > > > https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Howto… > > > . > > > > > > Or do you have such a guide I can just link to? > > > > > > > We're still finalizing the UI for the new features (QR code scanning, > > meek bridge type selection, etc) so once that is completed, we'll do a > > round of screenshots, guide updates, etc. This will most likely happen > > in early April. > > Wow, this is awesome! Great work, to all of you! > > Let me know if there's anything more I can do to help. In thinking about how users on phones/tablets will actually get obfs3/4/scramblesuit bridges, I realized that going to https://bridges.torproject.org on their mobile device will not be a great experience. The QR code scanning if they or a friend also has a PC, but in a pure mobile environment, it doesn't help so much. I can create a ticket for this, but just to lay out the idea, I think we need to have the bridge:// (or the improved proposed obfs4:// obfs3:// type specific scheme URLs) as a clickable link in both the bridges.tp.o site and the gettor email response messages. +n

2 1

Remove "*" from pluggable transports spec?
by David Fifield 20 Mar '15

20 Mar '15

I was going to write an email advocating for the removal of the wildcard '*' transport specification in pt-spec.txt. But then I saw that the current version of the spec doesn't mention the wildcard anymore; it was replace with a TODO in https://gitweb.torproject.org/torspec.git/commit/pt-spec.txt?id=4dcd7e94f17… "TODO: Document '*' transport" So how about we remove the TODO and just act like it never existed? Normally tor tells the transport plugin what transports to activate by giving it a string like "obfs3,obfs4"; but you're supposed to also be able to pass "*", which means "activate all transports you are capable of." Apparently this feature, though pyptlib and goptlib support it, has never been implemented in tor itself: Implement the wildcard "*" protocol in {Client,Server}TransportPlugin lines https://trac.torproject.org/projects/tor/ticket/3725 A wildcard specification doesn't really make sense, anyway. For one example, flashproxy-client knows two transport names, "flashproxy" and "websocket", which are synonyms. But if tor asks for "*", flashproxy-client shouldn't open up two listeners. Another case is fog (a dynamic transport combiner), which constructs a chain of transports from a transport name like "obfs3_websocket". The transports can be combined in infinite ways; it doesn't make sense to say, "activate all of them." https://lists.torproject.org/pipermail/tor-dev/2013-December/005966.html Let's just drop this part of the spec, and delete some underspecified and unused code? David Fifield

2 1

Re: [tor-dev] Fwd: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!
by Nathan Freitas 20 Mar '15

20 Mar '15

On Thu, Mar 19, 2015, at 06:58 PM, David Fifield wrote: > What would it take to get some screenshots that show how to turn on > pluggable transports? I would like to add a guide to > https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart and > instructions to > https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Howto… > . > > Or do you have such a guide I can just link to? > We're still finalizing the UI for the new features (QR code scanning, meek bridge type selection, etc) so once that is completed, we'll do a round of screenshots, guide updates, etc. This will most likely happen in early April.

2 1

thanks redditt
by Tyrano Sauro 19 Mar '15

19 Mar '15

2 1

Fwd: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez!
by Nathan Freitas 19 Mar '15

19 Mar '15

----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: [guardian-dev] Orbot v15 alpha 5 is out: MeekObfs4VPNQRCodez! Date: Thu, 19 Mar 2015 11:12:59 -0400 Orbot v15 alpha work is nearly done... APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-5.apk SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-5.apk.asc Highlights: * Updated to tor-0.2.6.4-RC * VPN / full device "Apps" mode is fully implemented and stable - no root needed to run all apps on your device through Tor * Meek and Obfs4 pluggable transports are now included and working quite well, even with the VPN mode * Easy scanning and sharing of bridge address QR codes from bridges.torproject.org * Removed integrated webview/webkit for now, since Android WebView is generally p0wn3d More at: https://gitweb.torproject.org/n8fr8/orbot.git/tree/CHANGELOG Thanks to nickm, isis, yawning, fifield, sandro, team psiphon and many others for all the various amazing pieces coming together to make Orbot v15 a very important and big release. +n -- Nathan of Guardian nathan(a)guardianproject.info _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscribe(a)lists.mayfirst.org

2 1

Performance and Security Improvements for Tor: A Survey
by Ian Goldberg 19 Mar '15

19 Mar '15

As I mentioned at the dev meeting, Mashael and I were just finishing up a survey paper on Tor performance and security research. The tech report version was just posted on eprint: https://eprint.iacr.org/2015/235 for your perusing pleasure. ;-) Thanks, - Ian

8 9

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

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

16 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 12 Mar '15

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

12 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