tor-dev

tor-dev@lists.torproject.org

5 participants
3594 discussions

Website Fingerprinting Defense via Traffic Splitting
by l.m 22 Jan '15

22 Jan '15

Daniel Forster wrote: > Hello Guys, > > it would be great if I could get a few opinions regarding my > upcoming master thesis topic. > > My supervisor is Andriy Panchenko (you may know some of his work > from Mike Perry's critique on website fingerprinting attacks). > As a defense, we'd like to experiment with traffic splitting (like > conflux- split traffic over multiple entry guards, but already > merging at the middle relay) and padding. > > I know that the no. of entry guards got decreased from three to one. > May it be worth the research or is the approach heading in a not so > great direction w.r.t. the Tor Project's "only one entry node" > decision? Or, actually, what do you think in general..? I think it will be interesting to see how a client of Tor can be fingerprinted by the guards chosen. In particular if the circuit length tends to be three and you perform a merge at the middle node. By watching the incoming n-tuple of guards, having chosen in advance the role of middle-hop, can clients be identified through correlation with exit traffic. I'm aware that the choice of guards can already make a client fingerprintable--but how much more so in this case. This might not be the adversary you're intending to address but is still a consequence. Unless I'm reading your proposal incorrectly. How might the possible threat be addressed. Perhaps a more robust implementation of network coding and a revisit of circuit length. I'm just throwing out thoughts. I too am interested in the application of network coding to the goals of Tor. I'll be eagerly awaiting your results. Good luck and thanks. -- leeroy

1 0

Re: [tor-dev] How Exit node decide which relay dedicated for particular http response.
by Ian Goldberg 22 Jan '15

22 Jan '15

On Thu, Jan 22, 2015 at 05:18:10PM +0100, Mohiuddin Ebna Kawsar wrote: > how "tor knows which socket belongs to which stream, and so to which > circuit" ? > which function handle this mapping?? I would guess it's the on_circuit member of the edge_connection_t struct, but others could probably give a more definitive answer. - Ian

1 0

How Exit node decide which relay dedicated for particular http response.
by Mohiuddin Ebna Kawsar 22 Jan '15

22 Jan '15

Hi, Suppose an exit node is acting as Exit for 2 different client connected by 2 different middle and guard node. suppose one of the client make http get request which will pass through Exit and TCP packet Header will be then [SENDER: EXIT NODE IP, RECEIVER: WEB-SERVER IP]. Now we have a reply from web-server. TCP HEADER [SENDER:WEB-SERVER IP , RECEIVER: EXIT NODE IP]. as this packet receiver is Exit node now how Exit node decide which relay it should pass the response data. means which client this response is for? is there any mapping or_connection to exit_connection? Regards Kawsar

2 1

lifespan of deprecated "ORListenAddress" configuration option
by Frédéric CORNU 22 Jan '15

22 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear all, The Tor Manual [1], as of today, says that ORListenAddress option is deprecated and that same behaviour can be achieved by specifying the listening address within the ORPort option. Although using ORPort to specify listening address works as expected whit tor, it causes arm to crash, see ticket #9269 [2]. You guys know how much relay operators rely on arm to check on their babies, and having tor operate on a specific IP address may not be such an uncommon practice. I don't know how both tor and arm projects coordinate their efforts, if they do, so the big question is : Can users expect support for ORListenAddress at least untill ticket #9269 is closed ? That would be nice [1] https://www.torproject.org/docs/tor-manual.html.en [2] https://trac.torproject.org/projects/tor/ticket/9269 - -- Frédéric CORNU http://wardsback.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlTAlLYACgkQieXg+ErX/wOKSAD+KFKO90dK0oMgW+lOOJ30TiEL Jxe4re8n4KUuKcEE1yYA/RHdxiyjH56yIR8lzmBIDyIouHgKd+xB2CvLLelJ5CDR =zrhG -----END PGP SIGNATURE-----

2 1

torify/torsocks and TCP Fast Open
by Tim Ruehsen 22 Jan '15

22 Jan '15

Hi, I tried to torify my wget-like application (https://github.com/rockdaboot/mget) and after some struggling I found that TFO is enabled by default (where available). I guess, the problem is TFO not using connect() but sendto(). Please enlighten me, what I can do (despite turning off TFO). Is it worth a patch or do you think patching libtorsocks has pitfalls or unwanted side-effects ? Tim

4 9

oppy - an Onion Proxy in Python
by Nik 22 Jan '15

22 Jan '15

Hi tor-dev, I care deeply about the ability for people to have anonymity online, and I've always been really interested in exactly how Tor works. So for a class project last semester I wrote oppy, an onion proxy in 100% Python. I spent most of my winter break cleaning it up and writing documentation, and today I'm releasing oppy as a free software project :) code: https://github.com/nskinkel/oppy docs: https://nskinkel.github.com/oppy Here's a brief description of the project, with some questions I have for tor-devs at the end. @@@ WARNING @@@ *DO NOT* use oppy if you want anonymity (see warnings on the project README and the documentation homepage). It's currently just a prototype and is not meant for normal client usage. --------- oppy works like a regular Tor client (i.e. any application that can use SOCKS 5 can use oppy), and it can even work with the Tor Browser Bundle if you fiddle with the TorButton settings to use oppy instead of the normal Tor process. See: https://nskinkel.github.io/oppy/usage.html There are a number of simplifications made, with the major ones primarily centering around circuit management/build logic and how and when network status documents are collected (see: simplifications.md in the repo or https://nskinkel.github.io/oppy/simplifications.html). So oppy doesn't currently work *exactly* the same as a standard Tor OP according to tor-spec. oppy seems to get reasonable performance (for an OP at least). I haven't done any serious performance tests so this is all anecdotal, but oppy seems to work fast enough for normal usage (e.g. I can generally stream videos without issues). I hope anyone on this list who is interested will try it out and/or have a look at the code! :) I have a few questions for tor-devs: 1. Do you think this project is/could be interesting, useful, or potentially beneficial as an addition to the world of Tor software? 2. If so, do you see any major use-cases for oppy? At this point it's still really just a prototype, so if anyone has some really cool use-cases for oppy I could try to design future modifications to support them. Some things I had considered so far: - a tool for research and/or rapidly prototyping new protocol modifications (e.g. new kinds of handshakes, circuit management behavior, or path selection) - a tool for testing/fuzzing Tor. With a few modifications, oppy could pretty easily be turned into a somewhat-advanced fuzzer (e.g. it'd be easy to do something like "After building C circuits and sending R relay data cells on circuit X, send N number of malformed cells of type Y to the middle node on circuit X"). - a drop-in OP replacement for specialized applications. oppy is still a pretty long way from this being a viable option, but maybe someday people could use oppy as a regular Tor client for certain use-cases (e.g. if someone wants to ship a full Python Tor stack for a locked down, special-purpose application using Tor). 3. If yes to 1 or 2, would anyone here be interested in hacking on oppy with me? :) I had a *ton* of fun building oppy and learned a lot about Tor in the process, and I'd love to continue working on it. I'm currently thinking about what a project roadmap for oppy could look like, but whether or not I continue hacking on oppy to make it a solid piece of software (rather than just a prototype) or just leave it as is as a reference depends on whether or not the Tor development community sees any real uses or future potential for the project. Thanks for reading! All the best, Nik

5 10

high latency hidden services
by Mansour Moufid 20 Jan '15

20 Jan '15

Hi everyone, Operation Onymous, the anecdotes about it (I don't think the DoS was a DoS), the wording of the related legal documents, and the previous CMU research... make me think that traffic confirmation attacks are now widely used in practice. Other, cat-and-mouse implemetation vulnerabilities may be diversions or parallel construction. This kind of attack would mean it's game over for HS that use HTTP or other low-latency protocols. Has there been research on integrating high-latency message delivery protocols with the hidden service model of location hiding? The SecureDrop or Pynchon Gate protocols sound like good starting points. I would love to participate, and encourage everyone to start in this direction (in your copious free time ;). Mansour

7 17

How to inform support of user-relevant issues?
by David Fifield 20 Jan '15

20 Jan '15

What's a good way to inform support of issues that users might run into? Should I just send email to help(a)rt.torproject.org, or is there a better way? I was thinking about this today because meek is broken in the 4.5-alpha series, but not in the main 4.0 series. I don't know if anyone told support workers about it, even though it might matter to them. https://trac.torproject.org/projects/tor/ticket/13788 https://blog.torproject.org/blog/tor-browser-45-alpha-1-released#comment-79… https://blog.torproject.org/blog/tor-browser-45-alpha-2-released#comment-81… David Fifield

2 2

Running doctor's sybil checker over archived consensuses
by Philipp Winter 20 Jan '15

20 Jan '15

I reimplemented doctor's sybil checker [0] in Go [1] which makes it possible to (somewhat) quickly analyse archived consensuses. The algorithm is quite simple. It iterates over every consensus ever published, keeps track of all relay fingerprints, and tells us how many previously unseen relay fingerprints are present in every consensus. I put the results, time series ranging from 2007 to 2014, online [2]. One can see a bunch of suspicious spikes in some of the years. I manually checked the events and summed them up below. But first, here are some basic statistics about the amount of new fingerprints: Min. : 0.000 1st Qu.: 4.000 Median : 6.000 Mean : 6.377 3rd Qu.: 8.000 Max. :3020.000 The median amount of new fingerprints in a consensus is six. The maximum number observed is 3,020 which was caused by the sybil attack last December. Here are some preliminary notes about the most significant spikes. I'll have a more detailed analysis at some point in the future. 2007-11-12: Missing consensuses. 2008-07-22: Missing consensuses. 2008-09-19: Some missing consensuses and a small group called "torism" came online. 2008-10-25: Missing consensuses. 2010-06-26: Several hundred PlanetLab relays came online. At least their nickname contained "planetlab" or some variation thereof. 2010-09-23: The trotsky relays which were suspected to be part of a botnet. 2010-10-02: Again trotsky relays. 2012-11-15: Several hundred clearly related relays, at least some of which in Amazon's EC2 IP address space, come online. 2013-02-04: A group very similar to the previous one comes online. 2014-01-30: A clearly related group of relays comes online, presumably the one from the pulled Blackhat talk. 2014-11-17: Several probably related relays in the Google cloud get online. 2014-12-26: Many relays named LizardNSA and FuslVZTOR come online. 2014-12-30: Many relays named anonpoke come online. [0] <https://gitweb.torproject.org/doctor.git/tree/sybil_checker.py> [1] <https://gitweb.torproject.org/user/phw/sybilhunter.git/> [2] <http://www.nymity.ch/new_fingerprints/> Cheers, Philipp

3 5

Consensus weight dropped
by Bram de Boer 19 Jan '15

19 Jan '15

All, In December consensus weight of many nodes suddenly dropped. Using the onionoo database I have calculated the average consensus weight during 18-25 october 2014, and the average consensus weight during 11-18 january 2015 of all relays that exist longer than half a year and sorted them by the amount the consensus weight has dropped: http://nosur.com/consensus.txt Almost all of the relays at the top of the list show the same drop in December and the short spike around januari 6th. The exits I operate used to contribute around 80 Mbps to the network but are now down to no more than 0.05 Mbps. I am aware of the Lizard Squad annoyance around that time, but the disruption seems to continue for many old relays. Has there been a change in the consensus calculation that might be causing this? Thanks, Bram de Boer

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev