- tor-dev - lists.torproject.org

Reduce RTT for preemptively built circuits (GSoC)
by ra 08 Jun '13

08 Jun '13

Hello everyone! During this year's Google Summer of Code I[0] will be working on reducing the Round-Trip-Time (RTT) for preemptively built circuits.[1] My mentors are Mike and Aaron. A brief summary of the project: RTTs of circuits can be measured by violating the exit policy of the exit node and the resulting error can be timed in a measuring client. It is assumed that the RTTs are Fréchet-distributed which could be used to reject a preemptively built circuit if its RTT is below a certain threshold value. A basic algorithm will be implemented to gather the required data for further statistical analysis which should help answering open questions like: • Are the RTTs Fréchet-distributed? • Does this strategy make new attacks feasible? • How many probes per circuit are needed to do reasonable estimations? • How much additional load is added to the network? • What is an appropriate cut-off percentile? • Does the strategy work in terms of anonymity and performance? • Does the RTT vary for destination ports? (This might be the case for destination ports that occur rarely in exit policies.) • Does this strategy also work if guard nodes are congested? Best, Robert [0] "ra_" on OFTC [1] http://www.google-melange.com/gsoc/project/google/gsoc2013/ra_/19001

2 1

Censorship Simulator Virtual Machine GSoC
by Arturo Filastò 08 Jun '13

08 Jun '13

Hi Johannes, I wanted to introduce you and your GSoC project to the list. The project is about building a virtual machine based censorship simulator. The goal is to have a way to test if the ooniprobe tests are working properly by simulating the network of a censor. Our goal is to actually run the software that a censor would be running (e.x. squid, bluecoat proxy sg va, etc.) and detect it's presence in an as real as possible environment. Johannes and Klaudiu analyzed a bit of the possible technological solutions to making this here: https://trac.torproject.org/projects/tor/wiki/doc/OONI/CensorshipSimulator. I think that the outcome is that we will be using Vagrant, meaning that this simulator could then be run on OSX, Linux and Windows. The kind of networks we will be creating are those where: * There is a transparent HTTP proxy * There is NAT * Certain sites are blocked thanks to HTTP headers * RST packets are sent when connecting to certain hosts * DNS based censorship is present If you have some ideas of things you would like to see in this, add ideas to this ticket: https://trac.torproject.org/projects/tor/ticket/7233, or create a page in the trac wiki nested under https://trac.torproject.org/projects/tor/wiki/doc/OONI/CensorshipSimulator. ~ Art.

2 1

Creating a p2p identity authentication protocol
by DataPacRat 07 Jun '13

07 Jun '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As suggested by Tor Project's helpdesk, I'm forwarding this message to tor-dev, in hopes that I might be able to evoke any useful references, suggestions or commentary. - ---------- Forwarded message ---------- From: Matt Pagan via RT <help(a)rt.torproject.org> Date: Fri, Jun 7, 2013 at 4:42 PM Subject: [rt.torproject.org #10568] Adapting 'tag' URI into p2p identity authentication system To: datapacrat(a)datapacrat.com You should subscribe to the tor-dev mailing list and bring this up on that public mailing list: https://lists.torproject.org On Fri Jun 07 18:02:44 2013, datapacrat(a)datapacrat.com wrote: > I'm working on the initial stages of a project which seems likely to > be of use to many who use the Tor protocol; and which could itself > likely benefit from the experience of the people who build and use Tor > extensively. > > I am currently looking into creating a new URI based on 'tag:' ( > http://www.taguri.org/ , https://tools.ietf.org/html/rfc4151 ) to use > for distributed reputation systems. I would like a common protocol so > that this idea can be easily expressed: "Authority A says that X and Y > are the same person" (with an optional field for the certainty of that > statement) (with an optional comment field) (with an optional > authentication hash). It seems likely to be simple to implement the > new URI (perhaps called 'nym:') in existing mail/contact software, so > that nym: links can be automatically imported into contact lists to > update them. > > Might you be interested in helping me work this out; or pointing me in > the direction of anyone else who might be? > > > Here's an initial draft of what I mean: > > > nym:Authority[,DateTime]:(Identity1)[,date];(Identity2)[,date][;(Identity3)[,date]][?comment1[&comment2][#authenticationHash] > > While based on 'tag:', there are a number of changes from that URI's > format: > > The authority can be not only an email address or a domain name, but > some other identifier, such as the URL of a social media profile, such > as http://twitter.com/DataPacRat or http://www.facebook.com/DataPacRat > . > > The date is no longer limited just to a particular date, but can be > specified (using ISO 8601 format) down to a particular second, for any > rapidly-changing identities. > > The identities can be plaintext names, social media profile URLs, > library card numbers, or any other chosen identifiers; though > regularly-formed URIs, email addresses, and domain names are most > likely to be most common. > > The comment fields are left incompletely defined, to allow for future > expansion; such as to indiciate trustcloud whuffie scores, how the > authority knows the individual being identified, or anything else that > someone comes up with. It seems a good idea to suggest the use of > existing fields from vCard and FOAF, to ease interoperability. > > By default, if a comment field is a number, that number is assumed to > be how confident the authority is that all the listed identifiers all > refer to the same individual, measured in decibans. (Decibans are > logarithmic, with 0 decibans being equivalent to 1:1 odds, or being > 50% confident; 10 decibans to 10:1 odds, or ~90% confident; 20 > decibans to 100:1 odds, or ~99% confident; and so on.) It is > recommended that these numbers be integers, unless there is a specific > reason to be able to specify confidence to greater accuracy; and with > a magnitude under 128, as it requires extraordinary effort to have 100 > decibans of confidence for even the most fundamental facts. > > (This method also implicitly allows for revocation of an identity > referral, simply by using a negative number instead of a positive > one.) > > The authentication hash is to provide strong evidence that the listed > authority is actually the one making the assertion. By default, it is > assumed to be based on whatever public cryptographic key (eg, > PGP/GnuPG or X.509) is linked to the listed authority ID; and that > what is being signed is the string of text before the hashmark. > > > This could allow for something like the following: > > nym:datapacrat@datapacrat.com:(datapacrat@datapacrat.com),2013-06- > 05;(http://twitter.com/DataPacRat),2013-06-05;(Daniel > Eliot Boese)?100&TrustCloud,774&Klout,29#randomhashofletters > > ... to indicate that as of that particular date, I indicate with > maximum confidence that my name, email address, and Twitter account > all point to me, and that I have two social media scores. (I would > have used 127 decibans instead of 100 if I'd just been asserting my > own identity.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJRskfVAAoJEBrKNlQrJtDDHWoIAKn6wCfrQhinNC6zCvf2D3eS CuSKB0XFPkm903ZwzA29aZKnhC6MJGO78Pu5pUuwZg0oWfB6zJshvmQR9A+QQdif s0Y84iNoeqVHqAqZgCk3sXPxqaNyEU2yEWREr09qNqVmuu6vhxODNInXf46PjV/6 BAlb26Ea75UwZfMpKY7rxYprTkIbkx3/55r16v8bZyKCKEkcb+0QQWf/pXA114eD Ec9YXIBEdPDrrhDOe2hAhJWI3ul3pcf/BK13Ch2ngSp757jxGJrz5QxmGNIu+bgQ Us1SPBS/e8JI9xX2xOa3p/CAh/McxfzFWqPO78t2v77bn/sl45WLfl4RoQ7ulvc= =9XrL -----END PGP SIGNATURE----- Thank you for your time, -- DataPacRat "Then again, I could be wrong."

1 0

Steganography Browser Addon (Google Summer of Code)
by Hareesan 05 Jun '13

05 Jun '13

Hi All, I'm Hareesan, I'm going to work on a browser extension (for firefox) in this summer to detect steganographically and asymmetrically encrypted content embedded in website content such as images, videos , audios and etc. At the same time these addons are caplble of encrypt contents steganographically inside the website contents. Detailed proposal and plans is available on [1]. [1] https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/rha… -- Hareesan R Undergraduate Department of Computer Science And Engineering University Of Moratuwa Sri Lanka

2 2

Moved pluggable transports bundle build scripts
by David Fifield 02 Jun '13

02 Jun '13

I've just moved the build files that were formerly in /flashproxy.git/doc to /pluggable-transports/bundle.git. This is a better place because the pluggable transports bundle doesn't really "belong" to flash proxy--rather the opposite. To build a pluggable transports bundle, follow the instructions in bundle-gnulinux.txt, bundle-macosx.txt, or bundle-windows.txt. In short, once you've set up the environment, you run for example make fetch-gnulinux-i686 make gnulinux-i686 The first command downloads a plain Tor Browser Bundle. The second unpacks the bundle, copies pluggable transports into it, and packs it back up. David Fifield

1 0

The ScrambleSuit pluggable transport / Philipp's May 2013 and earlier
by Philipp Winter 01 Jun '13

01 Jun '13

Over the last months, I have been working on a pluggable transport protocol called "ScrambleSuit" [1, 2]. It is one---but not the only---answer to active probing as done by the Great Firewall of China. Active probing allows the GFW to detect and block vanilla as well as obfs2 Tor bridges; and perhaps also obfs3 in the future. ScrambleSuit uses a secret which is shared out-of-band. In practice, this will be a long password distributed by BridgeDB. A ScrambleSuit server only responds if the client is able to prove knowledge of the shared secret. Besides, the protocol is able to randomise its packet length distribution and inter arrival times. The protocol header understands packet padding, so it would be possible to improve traffic analysis defence in the future. While ScrambleSuit will obviously work with Tor, it is also supposed to support protocols other than Tor---as long as they understand SOCKS. This should make it possible to tunnel, e.g., VPN traffic over ScrambleSuit. Implementation-wise, the protocol is a set of Python modules for obfsproxy. The source code is now available but still under development [3]; so please don't use it on real systems just yet. There are also two open tickets which need to be resolved before ScrambleSuit can publish its shared secret to BridgeDB [4, 5]. [1] http://www.cs.kau.se/philwint/scramblesuit/ [2] https://en.wikipedia.org/wiki/A_Scanner_Darkly [3] https://gitweb.torproject.org/user/phw/scramblesuit.git [4] https://trac.torproject.org/projects/tor/ticket/8929 [5] https://trac.torproject.org/projects/tor/ticket/8979 Cheers, Philipp

1 0

"Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization"
by Tom Ritter 31 May '13

31 May '13

RPW's, et al's paper was made public today, and demonstrates several practical attacks on Hidden Services. http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf I was wondering if there were any private trac tickets, discussions, or development plans about this that might be also be made public. -tom

6 9

obfs3 and Android
by Gordon Morehouse 30 May '13

30 May '13

Hi there, I know a user in China with an Android device who is having trouble with the GFW. I run private bridges for a couple friends in odd places and recently upgraded to obfs3, but after inquiring on IRC this morning I found that Android doesn't have obfs3 support yet: 17:17 < gamambel> gmorehou: unfortunately, not yet. someone has to either implement obfs3 in C, or make the new python obfsproxy work on Android. i don't think anybody is working on that yet. Just a quick question (apologies if it's a repeat) from a totally Android-naive developer: is using Jython a possibility to speed the availability of obfs3 on Android? Last I knew, which was in the dark ages, some Python code could be tortured into running on Android devices by compiling it with Jython. Just curious if this has been considered or not. I don't know what Android-specific problems there may be, but I know that in general Jython lags behind the latest stable Python, so e.g. code written against Python 2.7 might need to be tweaked to run against 2.5, etc. -- Sent from my device

4 6

Building better pluggable transports (Google Summer of Code)
by Steven Murdoch 29 May '13

29 May '13

Hi Chang, We've been discussing how to build better pluggable transports for Tor as part of your application to Google Summer of Code. Now that you've been accepted, I thought it would be good to bring this discussion to tor-dev so that others can contribute. The basic idea behind the project is to build a pluggable transport which is as unlikely has possible to be blocked. In particular, we are most interested in improving the situation in countries where obfs2/obfs3 is blocked or likely to be blocked in the near future. There are two basic options, which would ideally be combined: - Better camouflaging Tor traffic - Scanning resistance On better camouflaging Tor traffic, the benchmark we have is obfs3, which converts Tor traffic to data which is indistinguishable from random bytes (but timing and packet-size patterns are not disguised). As far as I'm aware, this is not being blocked anywhere but it may be possible to block based on the fact that there's not much truly random data on the Internet. Also, obfs3 will not get through a HTTP proxy, as it is clearly not HTTP. So one option for the project is to impersonate HTTP. This is deceptively difficult because although HTTP is transmitted over TCP, the properties it offers to higher layers are not as strong as TCP (and not as required by Tor). For instance, individual HTTP requests may be re-ordered if they are over different TCP connections. Also, responses may be truncated without an error being reported to higher layers (which is why HTTP includes length fields as an option). HTTP doesn't give the same congestion avoidance as TCP and proxies can both cache and modify data they transmit. The HTTP specification is vague on some topics, and even when it specifies a particular behaviour, proxies frequently violate the specification. On the up-side of a HTTP proxy, HTTP is probably one of the last protocols a country will block before they turn off the Internet completely, so it has a good chance of getting through. Also, in some scenarios the only way for traffic to get out is via a HTTP proxy. So I think there is significant usefulness in this option. Also, it is incredibly difficult to hide one protocol inside a different one, because just recording the approximate number of bytes sent vs bytes received can give a good recognition of the protocol [4]. Hiding HTTP-over-Tor as BitTorrent traffic will likely be detectable based on such a statistic, but HTTP-over-Tor as HTTP at least has a chance. On the side of scanning resistance, we discussed the challenge of implementing scanning resistance with TCP. Here, the problem is that someone sending a SYN packet to a port which is open will receive a SYN-ACK, regardless of what user code does. To resist scanning (with something like BridgeSPA [1]) the pluggable transport would need to be quite tightly integrated with the OS rather than just using the standard socket API. Therefore it will create deployment difficulties, especially on Windows which has locked-down the raw sockets API. Therefore it might be interesting to send data over UDP rather than TCP, as then it is the responsibility of the user code to send the SYN-ACK-equivalent. Tor needs properties similar to TCP from it's pluggable transport, and so any UDP-pluggable transport would need something which replaces TCP: reliable in-order delivery with congestion management. One option here is libutp, as used by BitTorrent [2]. There is a vast amount of libutp traffic on the Internet, but it's timing and upstream/downstream characteristics will be different from how Tor would use it. Alternatively, it might not be worth worrying about this type of scanning resistance, and just focus on what it is possible to do with TCP, as done with ScrambleSuite [3]. Chang, George, do you have anything to add to this summary? Does anyone else on tor-dev have thoughts on these topics? Best wishes, Steven [1] http://www.cypherpunks.ca/~iang/pubs/bridgespa-wpes.pdf [2] https://github.com/bittorrent/libutp [3] http://www.cs.kau.se/philwint/pdf/scramblesuit2013.pdf [4] http://dedis.cs.yale.edu/2010/anon/papers/parrot.pdf

7 10

Searchable Tor descriptor archive - GSoC 2013 project
by Kostas Jakeliunas 29 May '13

29 May '13

Greetings! I'm a student who will be working on the Searchable Tor descriptor archive as part of Google Summer of Code. Yay! I've been following Tor development for a while and hope that this opportunity will be my way of sneaking into the development kitchen of Tor. In any case, I hope to stay around for a longer time to come. The original GSoC project proposal is based on one of the Tor project ideas available [1] and is part of the Tor Metrics project [2]. The GSoC proposal itself is also available to read [3] (TXT; if there's any interest, I can work on reformatting.) My primary mentor is Karsten and my secondary mentor is Damian. I will quote the abstract from the proposal to sum up the high-level goals of this project: I'd like to create a more integrated and powerful descriptor archival > search and browse system. (The current tools are very restrictive and the > experience disjointed.) To do this, I'll write an archival browsing > application wherein the results are interactive: they may act as further > search filters. Together with a search string input tool which will have > more filtering options, the application will provide a more cohesive > archival browse & search experience and will be a more efficient tool. > So as of now, we have an array of tools for inspecting, searching for and getting aggregate data about running relays. (For an overview, see the Tools page in the Metrics portal. [4]) These tools include relay search, consensus info, exit-by-IP search, and quite a few more; furthermore, two Onionoo [5] based applications/tools: Atlas and Compass. This project would proposes to: - implement a more powerful backend that would allow one to search for all available relays since mid-2007 (I should have clarified in the previous discussions, and Karsten already includes this bit; i.e., since v2 statuses became available [6]; I guess this can also be discussed). "More powerful" here means, first and foremost, "all (>= v2) archival data" (relay descriptors and consensuses at the very least), and furthermore (at least per the original proposal), involving more complex queries: we'd be looking into, I think, minimally, combined AND/OR filters referring to a wider range of data fields available in the archival data and the ability to specify multiple date ranges. Referring to consensus-related data while searching for relays and vice versa would also be possible. (The capabilities would therefore also include those of exoneraTor.) - implement backend results which would, as of current standing, aim for Onionoo compatibility (again see protocol design in [5]), or perhaps supersede it while providing backwards compatibility (e.g. returning paginated lists of consensus-status-entries where a specified relay was present.) - (as per original proposal,) implement a more powerful archival descriptor search & browse tool (frontend) which would provide a more uniform "looking up relays" / "searching by using many criteria" / "further refining search in the results page" experience - "refining search results", i.e. adjusting filters would be semantically the same as entering search criteria in the beginning; hence a more interactive experience, a more powerful search/browse tool. The goals and design of the project have to be clarified, however. There is ongoing discussion (see another tor-dev thread [7] e.g.) whether perhaps the focus could be to create a backend which would speak the full Onionoo protocol and therefore be a potential replacement not only for relay search and exoneraTor, but also for other components: all presently-speaking Onionoo applications could be made to talk to the new backend, for example. The overall count of components will hopefully be reduced in any case, but ideally, we would end up with a much more integrated Tor Metrics (and maybe beyond) ecosystem. Many open questions, however - see again [7]. Obviously discussions are very welcome indeed! I'm wfn on OFTC (#tor-dev, #nottor), also reachable via XMPP < phistopheles(a)jabber.org>, and am very much up for any kind of chat. :) I'll be busy with exams in the first three weeks of June, though - but will find time for sure! Regards Kostas. [1] https://www.torproject.org/getinvolved/volunteer#metricsSearch [2] https://metrics.torproject.org/ [3] http://kostas.mkj.lt/gsoc2013.txt [4] https://metrics.torproject.org/tools.html [5] https://onionoo.torproject.org/ [6] https://metrics.torproject.org/data.html#relaydesc [7] https://lists.torproject.org/pipermail/tor-dev/2013-May/004940.html

1 0