tor-dev June 2013

tor-dev@lists.torproject.org

54 participants
48 discussions

Pluggable transport bundles with websocket transport
by David Fifield 09 Jun '13

09 Jun '13

I have made new experimental pluggable transports bundles with support for the websocket transport. We hope this transport looks enough like HTTP to get past certain firewall filters. https://people.torproject.org/~dcf/pt-bundle/2.4.12-alpha-2-websocket1/ If the transport name websocket sounds familiar, that's because it's the same transport used by flash proxy. The difference here is that you connect directly to the bridge, rather than going through a browser proxy. The actual software is the websocket-client program from here: https://gitweb.torproject.org/flashproxy.git/tree/HEAD:/websocket-transport Due to a build SNAFU, the OS X packages have the flashproxy transport disabled, with only obfs2, obfs3, and direct websocket enabled. The other platforms have all transports enabled. We would like to have some more fast websocket relays to include in the default torrc in a future release. If you can do this, see the section "How to run a relay" from https://gitweb.torproject.org/flashproxy.git/blob/93be0302:/README#l100 Send the IP address and port of your relay to tor-assistants(a)lists.torproject.org. David Fifield

1 0

Ideas for metrics of the safety of the Tor network
by George Kadianakis 08 Jun '13

08 Jun '13

A year ago or so, during FOCI '12, with the help of some smart people [0] I compiled a list of interesting metrics/visualizations that could help us understand the security of the Tor network. Since even more people are interested in metrics lately, I thought of posting this list here, in case it inspires someone (better than letting it rot unseen). Note that some of the stuff in the list might have been implemented already, and there are also some upcoming academic papers that explore this area. Also, check out https://trac.torproject.org/projects/tor/ticket/6460 In any case, I'm inlining the list: """ 1 Attacker strategy 1.1 Are there certain geographic or network locations where adding relays with a given capacity will most influence your safety metrics? This influence could be positive ("where should I put my relay to best help the Tor network?") or negative ("where should I put my relay to best attack users?"). 1.2 What happens to the network if X relays are compromised? 1.2.1 All Windows relays. 1.2.2 All relays running old Tor versions. 1.2.3 All "top 10% relays" are compromised... 1.3 How much bandwidth do I need to compromise, in order to compromise a random user's path in a given timeframe 1.3.1 Use 'guessing entropy'? 1.4 Is there a difference between compromising a '5Mbit relay' and 'five 1Mbit relays'? Should there be a difference? 1.5 Change classic Tor formula to start considering bandwidth load balancing. 1.5.1 "If an adversary controls m out of n nodes, he can correlate at most (m/n)^2 of the traffic." should consider bandwidth 1.6 See how many exits are exiting on a different IP than the one they accept traffic? (they can sniff twice) 2 Network diversity 2.1 How many relays are running old Tor versions? 2.2 Fraction of paths that have the entry and exit at the same country/AS. 2.3 Fraction of paths that pass twice through AMS-IX/LINX/DE-CIX. 2.4 What happens to the network if we discard relays of certain characteristics? 2.4.1 What happens if we discard the slowest relays? 2.4.2 What happens if we cap the fastest relays? 2.4.3 Discard paths with expected high latency (http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf) 2.5 If only a given fraction of exit relays support IPv6, how much does it reduce your anonymity to be going to an IPv6-only destination? 2.5.1 Should we add a fourth hop, like we do in exit enclaving? 2.6 Is there any relationship between the rate of new relay arrival (e.g. during political events or after popular conferences) and the level of diversity of these relays? 2.7 Graph showing "the X% of the relays see Y% of the traffic" 2.7.1 example, "The 5% of the relays route 55% of the traffic"... 2.7.2 Lorenz Curve / Gini coefficient (Used in "Improving Security and Performance in the Tor Network through Tunable Path Selection") 2.8 Measure router families and how much bandwidth they control/how many circuits they can compromise. 2.9 What is the security difference if families did not exist? 2.10 How much does the /16 subnet restriction influence path selection? 3 Optimization results 3.1 Robustness over time: is an adversary that can knock out X% of the capacity in the network (for various values of X) getting more or less influential as the network grows? How about an adversary who can knock out an absolute capacity of K bytes for various values of K? 3.1.1 Look at the vailability/uptime/whatever of relays and YOU decide which relay has the guard flag. 3.1.2 Is weighted uptime the correct way of assigning a guard flag? Relay with 4 days of uptime gets flag, relay with one day down and three weeks of uptime does not get the guard flag. 3.2 If we give out Guard flags according to some other algorithm, how much safety can we get back? 3.2.1 Safety measures 3.2.2 Alternative guard algorithms 3.3 In Tor 0.2.1.x we started load balancing based on active bandwidth measurements, so we use the bandwidth weights in the network consensus rather than the weights in each relay descriptor. We know that change improved performance, but at what cost to safety? 3.4 What happens to the network diversity if we put a low cap on the bandwidth weighting of any node that hasn't been assigned a measurement by the bandwidth authorities yet, to protect against relays that lie about their bandwidth? If there's no real effect, we should do it; but if there's a large effect, we should find a better plan. 3.5 What if some Tor users choose their paths to optimize a different network property (like latency or jitter), as suggested by Micah Sherr? The infrastructure you've built to measure diversity here should apply there too. 4 Notes 4.1 Modularize the path selection code of pytorctl for researchers to use. 5 Papers to read 5.1 Trust-based Anonymous Communication: Adversary Models and Routing Algorithms 5.2 Latest version of Tariq's "Changing of Guards" paper 5.2.1 Look at "Closed Analysis" section in appendix 5.3 Improving Security and Performance in the Tor Network through Tunable Path Selection 5.4 Metrics for Security and Performance in Low-Latency Anonymity Networks (PDF) (Cached: PDF) """ [0]: the list includes Aaron Johnson, Ian Goldberg, Tariq Elahi, Roger, Nikita Borisov, and more that I can't remember right now.

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev June 2013