[tor-dev] Dumb or-ctl-filter tricks (Was: [tor-talk] SOCKS proxy to sit between user and Tor?)
Hello, I just pushed a fairly large update to or-ctl-filter, that lets you do lots of interesting things, most of them probably unsafe. In particular or-ctl-filter now ships with a SOCKS5 client/server implementation and a stub control port implementation. A picture is worth a thousand words: https://raw.github.com/Yawning/or-ctl-filter/screenshots/or-ctl-filter-tor-i2p.png What it does: * Filters the control port exposed to Tor Browser for things that (IMO) the browser has no business knowing just in terms of attack surface. In particular this intentionally breaks the circuit display feature as part of 4.5.x. * Allows easy integration of Tor Browser with a system tor service (NB: I run a system tor service with the Tor Browser circuit lifespan patch, if you do not, you will get behavior that is different from other users. You have been warned.) * Supports transparently redirecting .i2p requests to an I2P instance. Tor does not need to be running for this. * Enforces isolation to attempt to guard the local I2P web server and management interface from cross protocol trickery, evil Javascript and whatnot. * Supports running without Tor or I2P at all, essentially changing Tor Browser into Firefox with a bunch of patches. Limitations: * NEWNYM does not affect I2P tunnels. * New Tor Circuit For This Site does not affect I2P tunnels either. * Only cookie authentication is supported because I'm lazy, and it is the superior authentication method. * Launching Tor/I2P is not or-ctl-filter's problem and will never be part of the feature set. I have systemd for that. Warning(s): * Very alpha. It is entirely possible that I screwed up enforcing isolation. You can hard disable access to locally hosted i2p services like the management console in the config file. It is still probably 3 million times better than using privoxy/random sketch addons to do something like this because I actually do look at circuit isolation from Tor Browser and propagate it to Tor (or enforce it as best as I can otherwise). * If you enable logging, it will happily splatter destinations, authentication credentials, and everything else to the log, because it is a debugging feature, so don't. * If you enable the option named UnsafeAllowDirect and disable Tor, it will happily connect directly to the internet, destroying your anonymity. * Untested on Windows. Should work, don't care if it doesn't. Patches will sit in my INBOX forever; ignored, and unloved, just like the operating system they target. The same goes for OSX.[0] Code: https://github.com/Yawning/or-ctl-filter/tree/master -- Yawning Angel [0]: Honestly, I'll merge trivial things, but I won't bust out my windows box to test/debug this, and I don't have an OSX box. pgp4kvHS2QXRf.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Researching Tor: Quantifying anonymity against a global passive adversary
This is my favorite paper on quantifying anonymity: http://dimacs.rutgers.edu/Workshops/Anonymous/bagai.pdf -V ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Researching Tor: Quantifying anonymity against a global passive adversary
Hi there, I am currently writing my Master's thesis about Mix networks Tor (was on list previously). I am currently at a point, where I'd like to practially quantify anonymity. That is, given a pcap, I want to anaylze how successful an adversary can determine whether a specific client talked to a specific service. Since I run all of this in a simulation (using Shadow), I have access to ground truth and can determine the traffic, network size, etc. arbitrarily. The idea behind all of this is to integrate a Mix relay on each Tor node and to watch how the adversarys success behaves. However, I have a hard time finding material on such attacks, i.e. papers that closely examine this scenario (and perhaps have conducted some simulation and/or measurements themselves, beyond simple theory). The thing is that this is only part of the research and I'd really prefer if I could build this upon work of others instead of starting from scratch. Do any of you know of such papers or corresponding research? Regards, Florian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Dumb or-ctl-filter tricks (Was: [tor-talk] SOCKS proxy to sit between user and Tor?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/03/2015 04:07 PM, Yawning Angel wrote: Hello, I just pushed a fairly large update to or-ctl-filter, that lets you do lots of interesting things, most of them probably unsafe. In particular or-ctl-filter now ships with a SOCKS5 client/server implementation and a stub control port implementation. A picture is worth a thousand words: https://raw.github.com/Yawning/or-ctl-filter/screenshots/or-ctl-filter - -tor-i2p.png [snip] Thanks Yawning, this looks very useful indeed. - -Jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVb9z2AAoJEAHN/EbZ1y06U+kP/i2PRpJqRYqGksASUkYCZDcg q7Z1OLldOlT9EC2xjh8k/dEJi2or6in+hUSZPp6VNi9W3/drKX0t0VAY2zRmQzdr yfwm4e+FgFkenKUgGB9XOIus589Rclieri3nWhYwBqbOJIWLy9D4Ujassoj7PKpZ HNQXeg2cS3p2wGnku7NR6K13c2P7ajWV4aykTUJQDYUC2IqFw8LLK9zhxLOC98Lh WQ2HAtT1GsphC8jAygdk7XTmhOYL7i7n4jFgIhUB9dcI9YnbqxZsE4QrlkDAoiQg tzIIaJDAbensTFwiuR31cO7jA6yDEZ7Ikm6FhO1W3qW/YtjOs0mWr+zcp6cwOrKZ 0eKwHMRzAKJSNJLe0TIlr3gXbF/c/b8ACBcb6Si/QfeoGLy7nvDKDoi8URvhrmYG i77Faall1+ycFCWQgwik5JRo2XWWK3tXmMITqEMM3h2G1LOao4rH44QCYvA8xYtA CbwvVu0+od9eJyIQYk7gfYmP89ZTno/a+XiIgRdWEdLzTiUZb09WgtXM/E/qenG/ p80fNiphH6BhvkUsIWOKooJAs/vgeixM9QCGaTl+Nojvt/nru6PcRJ9hL9ulS8TO 9NxQ5hVu2A2jbGracHcZw9+5u7HqzxfOM9B6mSyYeWJ/T54PFgxT4PCJ3/D1idpk 8EBVAVWJETXTZHHEvHLF =QjQQ -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Researching Tor: Quantifying anonymity against a global passive adversary
Hello Florian, I just saw your mail on tor-dev. The assumption a number of us have been using in our work, is that if the adversary observes a circuit at two different locations, then it can link it. This is a bit like assigning a unique ID to each circuit, and assuming that seeing the link / node on which the circuit operates, reveals this ID. Then you can use techniques such a monte-carlo simulation to evaluate the probability say Alice is talking to Bob as described in this paper: The Bayesian Traffic Analysis of Mix networks. Carmela Troncoso and George Danezis. ACM CCS 2009. Also: what are your plans for the future? I am advertising a PhD on this topic if that is something that would interest you: http://www0.cs.ucl.ac.uk/staff/G.Danezis/positions.html Best, George On Wed, Jun 3, 2015 at 12:38 PM, Florian Rüchel florian.ruechel@inexplicity.de wrote: Hi there, I am currently writing my Master's thesis about Mix networks Tor (was on list previously). I am currently at a point, where I'd like to practially quantify anonymity. That is, given a pcap, I want to anaylze how successful an adversary can determine whether a specific client talked to a specific service. Since I run all of this in a simulation (using Shadow), I have access to ground truth and can determine the traffic, network size, etc. arbitrarily. The idea behind all of this is to integrate a Mix relay on each Tor node and to watch how the adversarys success behaves. However, I have a hard time finding material on such attacks, i.e. papers that closely examine this scenario (and perhaps have conducted some simulation and/or measurements themselves, beyond simple theory). The thing is that this is only part of the research and I'd really prefer if I could build this upon work of others instead of starting from scratch. Do any of you know of such papers or corresponding research? Regards, Florian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
