tor-dev August 2014

tor-dev@lists.torproject.org

72 participants
90 discussions

Prototype Primitives for Website Traffic Fingerprinting defenses
by Mike Perry 28 Aug '14

28 Aug '14

Hello all, What follows is a summary of the primitives that Marc Juarez aims to implement for his Google Summer of Code project on prototyping defenses for Website Traffic Fingerprinting and follow-on research. After a review of Tamaraw[1], Adaptive Padding[2], CS-BuFLO[3], and the Supersequence[4] work, as well as some discussion at the Tor dev meeting, we came up with this list of padding message primitives. These functions are meant to be sent as command cells from one endpoint to the other. Some are bidirectional commands, others can only be sent in one direction (client to relay, or relay to client). For now, they will be implemented as ad-hoc messages between two modified obfsproxy (called wfpadtools) instances. The source code for this fork lives here for the moment: https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools/ Long term, I am thinking that all of these should be specified as if they were their own RELAY_* cell type from tor-spec.txt: https://gitweb.torproject.org/torspec.git/blob/HEAD:/tor-spec.txt#l1215 This means that padding would be a circuit-level property, and it would be possible to send it to and from any hop in the circuit, due to leaky-pipe topology (using the "recognized" field). In a world of very cheap and excessive middle and Guard node bandwidth, we would run this padding to the middle node. For the wfpadtools prototype, it will obviously only cover the first hop. Here's the list of primitives, broken down by research paper: Generic Messages (common to all defenses): RELAY_IGNORE() Description: Simple fixed-length (CELL_SIZE) padding cell. Direction: Bidirectional (client to relay, relay to client) Parameters: None RELAY_SEND_PADDING(N,t) Description: Send the requested number of padding cells in response. Direction: Client to relay Parameters: N: Number of padding cells to send in response to this cell t: microseconds delay before sending RELAY_APP_HINT(session_id, status) Description: A hint from the application layer for session start/stop Direction: Client to relay Parameters: session_id: A string identifying the session (ie keyed hash of url bar domain) status: "Start" or "Stop", indicating session start and end. Adaptive Padding Messages: RELAY_BURST_HISTOGRAM(histogram[], labels_ms[], remove_toks, fuzz, when) Description: Specifies a histogram that encodes a delay distribution representing the probability of sending a single padding packet after a given delay in response to either an upstream cell, or a client-originating cell. Direction: Client to relay Parameters: histogram[]: Contains delay distribution of sending an IGNORE packet after sending a real packet labels_ms[]: millisecond labels for the bins (with "Infinity"/"Ignore" bin to allow encoding the probability of not sending any padding packet in response to this packet). remove_toks: If true, follow Adaptive Padding token removal rules. If false, histograms are immutable. fuzz: If true, randomize the delay uniformly between bin labels. If false, use bin lables as exact delay values. when: If set to "receive", this histogram governs the probably of sending a padding packet after some delay in response to a packet originating from. If set to "send", this histogram governs padding packets that are transmitted after a packet arrives from upstream (the middle node). In both cases, the padding packet is sent in the direction of the client. RELAY_GAP_HISTOGRAM(histogram[], labels_ms[], remove_toks, fuzz, when) Description: Specifies a histogram that encodes a delay distribution representing the probability of sending a single additional padding packet after a given delay following a padding packet that originated at this hop. Direction: Client to relay Parameters: histogram[]: Contains delay distribution of sending an IGNORE packet after sending an IGNORE packet labels_ms[]: millisecond labels for the bins (with "Infinity"/"Ignore" bin to allow encoding the probability of not sending any padding packet in response to this packet). remove_toks: If true, follow Adaptive Padding token removal rules. If false, histograms are immutable. fuzz: If true, randomize the delay uniformly between bin labels. If false, use bin lables as exact delay values. when: If "receive", this histogram applies to locally-inserted padding packets that were initially sent in response to client-originated data. If "send", this histogram applies to packets sent in response to locally-inserted padding packets sent in response to upstream data. Note that this means that implementations must maintain this metadata as internal state as the system transitions from BURST_HISTOGRAM initiated padding into GAP_HISTOGRAM initiated padding. In both cases, the padding packet is sent in the direction of the client. CS-BuFLO Messages: RELAY_TOTAL_PAD(session_id, t): Description: Requests that endpoint pad all batches to nearest 2^K cells total or until APP_HINT(session_id, stop) Direction: Client to relay Parameters: session_id: The session ID from APP_HINT() t: The number of microseconds to wait between cells to consider them part of the same batch. RELAY_PAYLOAD_PAD(session_id, t, R): XXX: The paper was not clear enough for me to understand this primitive Tamaraw: RELAY_BATCH_PAD(session_id, L, t) Description: Requests that endpoint pad all batches of cells to L cells total or until APP_HINT(session_id, stop) Direction: Client to relay Parameters: session_id: The session ID from APP_HINT() L: The multiple of cells to pad to. t: The number of microseconds to wait between cells to consider them part of the same batch. Comments, questions, and suggestions are welcome! In particular, I'm not sure I got either the CS-Buflo or the tamaraw primitives completely correct. 1. http://cacr.uwaterloo.ca/techreports/2013/cacr2013-30.pdf 2. http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf 3. http://arxiv.org/abs/1401.6022 4. http://cacr.uwaterloo.ca/techreports/2014/cacr2014-05.pdf -- Mike Perry

1 2

Tor Data Leak
by sureyourejoking＠aim.com 28 Aug '14

28 Aug '14

To Whom it May Concern, I recently noticed that Tor Browser was leaking data about websites I visited in Tor to my hard drive. I am running Mac OS X 10.6.8 on a 2010 model Macbook Pro 6,2. I am using TorBrowser Version 3.6.3. The data appears in the directory "/Users/Username/Library/PubSub/Feeds/", where "Username" represents my username. The directory contains xml files with random names and a .xml extension. They contain text and url's from websites which I have only visited using Tor. I use "No-Script" in Tor, and it is active by default. "No-Script" was active when I visited all of the websites, except for youtube, since the videos will not play while "No-Script" is active. I have installed the following add-ons to Tor: "Adblock Edge 2.1.4" and "Privacy Badger Firefox 0.2.1". I noticed these xml files a month ago, and moved the contents of /Users/Username/Library/PubSub/ to a separate location. Since then, I have watched the contents of this directory closely. Two days after I deleted the contents of "PubSub", a directory called "Database" appeared containing a file called "Database.sqlite3". This file seemed not to have any information about websites I visited. A while later, the "Feeds" directory appeared, but was empty. The "Feeds" directory remained empty for about two weeks. Yesterday, xml files appeared in the Feeds directory, which now contains 1.1 MB of files. Is this a security bug in Tor Browser?

2 1

[RELEASE] Torsocks 2.0.0 stable
by David Goulet 25 Aug '14

25 Aug '14

Hi everyone! Following the discussion of bug #10007[1], this is the *stable* release 2.0.0 for torsocks. Nothing major went in since -rc7, see the change log below. 2014-08-11 torsocks 2.0.0 * Fix: compilation issue on Debian kfreebsd-i386 * Fix: add LICENSE file to repository * Fix: add compilation requirements to README.md Again, as usual, and forever! *please* code review, test and most importantly report any issues. Contribution ftw! :) Thanks to everyone! Git: https://gitweb.torproject.org/torsocks.git Tarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.0.0.tar.bz2 (sig: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.0.0.tar.bz2.asc) Cheers! David [1] https://trac.torproject.org/projects/tor/ticket/10007

2 1

Call for testing/review: obfsclient-0.0.1
by Yawning Angel 25 Aug '14

25 Aug '14

Hello all, I just tagged the obfsclient v0.0.1 (Release) Download at: https://github.com/Yawning/obfsclient/releases/tag/v0.0.1 Major changes since 0.0.1-rc2: * Invalid padding lengths in obfs3/ScrambleSuit handshakes are now correctly handled. * Handshake timeout is now set to a random interval between 60 and 120 seconds. * The ScrambleSuit probability distributions are now closer to what obfsproxy generates. * "--version" will now cause obfsclient to print the version and exit. * Various code cleanups. Some notes about ScrambleSuit: * I reverted the "workaround" I had for bug #11100, so Session Ticket handshakes to bridges running obfsproxy 0.2.6 will fail if they have been running long enough to trigger the bug condition. * Actual protocol behavior is closer to obfsproxy than my previous releases, but still not identical to 0.2.7. the next obfsproxy release will close the difference further. Hopefully it is of some use to people. Special thanks to Fabian Keil for help testing and fixing the various release candidates. Questions, comments, feedback appreciated as always, -- Yawning Angel

2 4

Damian's Status Report - August 2014
by Damian Johnson 24 Aug '14

24 Aug '14

Hi all, getting my status report out of the way a tad early. Deadlines for my day job at Amazon required working a weekend so April was mostly spent just getting caught up on code reviewing contributions... * Nick Mathewson greatly improved Stem's performance at parsing consensus documents. Thanks Nick! (#12859) * Rewrote Nick Hopper's patch for verifying consensus signatures. I'd really love to merge it, but it needs tests first. (#11045) * Code reviewed federico3's addition of better Controller methods for handling hidden service config options. (#12533) * Fixed stylistic issues cited by the newly released pep8 1.5.7, and also corrected a handful of python 3.x test failures. * Code reviewed a BridgeDB change to take advantage of Stem for isis. (#9380) * GSoC finals are finished! This year had a lower pass rate than we usually do (four of our thirteen students didn't pass), but I don't think there's necessarily any lessons to draw. This concludes my backlog of things I owe other people, so next up I'll finally be getting back to arm development! -Damian

1 0

[GSoC] Consensus diffs - Sixth report
by Daniel Martí 24 Aug '14

24 Aug '14

Hello everyone, This is the sixth and last status report of my Google Summer of Code project, which is to implement consensus diffs for Tor. Two weeks ago I had two main tasks left for the project to get to a minimal functioning state. The first was to figure out a clean way to cache old consensuses on disk. The second was to write the fetching of consensus diffs, and the corresponding serving of consensus diffs via spooling. Both of these were done, and last week I was able to launch a small local network via chutney and finally see consensus diffs be properly generated, served, fetched and applied. The hard pencils down date is tomorrow evening. I want to polish things up a bit and try to find last-minute bugs. Of course there will be quite a bit of work left once GSoC is over to get the outcome of this project included in Tor. Other than that, I'm quite happy with how the project turned out. I intend to continue contributing to Tor, at least to the extent of getting the code merged into master and fixing any bugs that may arise until it is suitable for a stable release. I'll continue pushing my work on Github [1] for now. See the "readme" branch for reference on what the consdiff-N branches mean. Regards. [1] https://github.com/mvdan/tor -- Daniel Martí - mvdan(a)mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C

3 2

Reminder: OONI dev meetings Friday 15:00 UTC (17:00 CET)
by Arturo Filastò 21 Aug '14

21 Aug '14

Hello Oonitarians, This is a reminder that the weekly dev meeting will be happening on the #ooni channel on irc.oftc.net this Friday (tomorrow and every following Friday) at 15:00 UTC (17:00 CET). Everyone is invited. ~ Art.

1 0

Fwd: [guardian-dev] Orfox: New Firefox-based Android Private/Secure Browser
by Nathan Freitas 21 Aug '14

21 Aug '14

Nice outcome from GSoC! I think the primary discussion here is whether Tor Browser's existing build system can be extended for Android, and whether "Orfox" should exist at all as separate app/project. -------- Forwarded Message -------- Subject: [guardian-dev] Orfox: New Firefox-based Android Private/Secure Browser Date: Wed, 20 Aug 2014 12:49:33 -0400 From: Nathan of Guardian <nathan(a)guardianproject.info> Organization: The Guardian Project To: guardian-dev <guardian-dev(a)lists.mayfirst.org> Based on work done this summer by Amogh Pradeep during his Google Summer of Code stint with me, we now have a real working version of Firefox/Fennec for Android with all the necessary defaults changed to match Tor Browser's defaults as closely as possible. We also remove the Android permissions for things like camera, mic, GPS and turn off webrtc. You can see the primary commits we've made here (many by me, but started successfully by Amogh): https://github.com/guardianproject/gecko-dev/commits/adaa37949dbba690ed0392… We still need to figure out which preferences and features map between the desktop mobile browser and the Android version, so there is quite a bit of work to do. For instance, even though the preference from Tor Browser is set to start in private browsing mode, it doesn't work at all in the Android app. Also, we haven't applied any of the lower level source patches to the gecko engine yet, or included any of the default extensions like HTTPS Everywhere or NoScript. Sorting out and resolving these differences is what is on deck for this fall, and everyone is welcome to join in. In addition, the recent audit work from iSec (https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardeni…) is also on our minds, and figuring out how we can live up to the goals of that study on a mobile device is also very important. The current build successfully passes the DNSLeakTest.com tests and passed the HTML5 video leak issue here: http://xordern.net/why-you-really-shouldn't-use-orweb-anymore.html ip-check.info still doesn't see the browser as being Tor Browser, so there are some differences yet to resolve there. The whole project is automatically building on our jenkins server, and you'll find all the links to APKs and our test build repo below. Over the next few months we hope to launch this as our new official browser for Orbot, and deprecate Orweb as quickly as possible. *** Main project repo: https://github.com/guardianproject/OrfoxFennec Our fork of Mozilla's Gecko-Dev: https://github.com/guardianproject/gecko-dev/tree/adaa37949dbba690ed0392c1f… (which we can rebase on the original as needed) Nightly/dev builds direct APK download here: https://guardianproject.info/builds/OrfoxFennec/ OR our fdroid test build repo: https://dev.guardianproject.info/fdroid/repo?fingerprint=F8ED4C73C125E7A67F… *** +n _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpr… You are subscribed as: nathan(a)guardianproject.info

3 5

GSoC : Rewrite Tor Weather (Status Update 6)
by Sreenatha Bhatlapenumarthi 19 Aug '14

19 Aug '14

Hey folks! This is my 6th and final GSoC status update on the Weather-Rewrite project. Things I worked on since my last update : - Wrote a small python script to clear the subscription data stored in the django models of the weather database before running the standalone scripts. This is particularly useful while testing the site. - Fixed some bugs in the daily script. - Tested the whole thing after removal of the consensus event-listener mechanism with file-based SMTP backend as well as gmail SMTP server with a test email setup. - Modified the standalone daily/hourly scripts to work as custom django management commands as suggested in #10706. - Updated documentation regarding the shift in data backend to Onionoo. - Style-aligned the code base with PEP8. To review the code, check out https://github.com/meejah/tor-weather/tree/develop As a note on collaborating with the Tor community during this summer through GSoC, I want to mention that I had great time with this and will try to keep making meaningful contributions via various development activities. Thank You for the experience. Cheers, Sreenatha

1 0

ooniprobe 1.1.0 is out!
by Arturo Filastò 19 Aug '14

19 Aug '14

Hello beautiful humans! We are very pleased to announce that a new version of ooniprobe is now out. In this new release of ooniprobe we have added a new command line tool for listing the reports that have not been published to a collector and that allows the probe operator to choose which ones they would like to upload. We have also made some privacy improvements to the reports (we will sanitize all things that may look like file paths) and added metadata associated with the maxmind database being used by the probe operator. Here is a more detailed list of what has been done: * Annotate on disk which reports we have submitted and which ones we have not: https://trac.torproject.org/projects/tor/ticket/11860 * Add tool called oonireport for publishing unpublished ooniprobe reports to a collector: https://trac.torproject.org/projects/tor/ticket/11862 * Probe Report does not leak filepaths anymore: https://trac.torproject.org/projects/tor/ticket/12706 * Reports now include version information about the maxmind database being used: https://trac.torproject.org/projects/tor/ticket/12771 * We now do integrity checks on the ooniprobe.conf file so that we don't start the tool if the config file is missing some settings or is not consistent: https://trac.torproject.org/projects/tor/ticket/11983 (thanks to Alejandro López (kudrom)) * Improvements have been made to the sniffer subsystem (thanks to Alejandro López (kudrom)) * Fix the multi protocol traceroute test. https://trac.torproject.org/projects/tor/ticket/12883 Minor bug fixes: * Fix dns_spoof test (by kudrom) https://trac.torproject.org/projects/tor/ticket/12486 * ooni might not look at requiresTor: https://trac.torproject.org/projects/tor/ticket/11858 * ooni spits out gobs of tracebacks if Tor is not running and the OONI config says it will be: https://trac.torproject.org/projects/tor/ticket/11859 * The README for ooni-probe should mention the bugtracker and repository https://trac.torproject.org/projects/tor/ticket/11980 For the moment you can download the new version from pypi here: https://pypi.python.org/pypi/ooniprobe. Soon a there will also be a new debian package for it (thank to Lunar^). As always feedback is greatly appreciated so please submit any bugs you may find to our bug tracker: https://trac.torproject.org/projects/tor/newticket?component=Ooni Have fun! ~ Art.

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev August 2014