- tor-dev - lists.torproject.org

SkypeMorph
by Hooman 09 Apr '12

09 Apr '12

Greetings, A while ago the Tor project rolled out Obfsproxy as a Browser Bundle [1], for users behind firewalls filtering SSL or detecting other characteristics of a Tor connection, to help them access bridges. In our recent work, SkypeMorph [2], we have tried to use Skype video communications as our target protocol for protocol obfuscation. SkypeMorph functionality is similar to Obfsproxy, but the connection between the bridge and the client looks like a Skype video call (the details of how we do this is discussed in the technical report). We also have an open-source proof-of-concept impelmenation of the SkypeMorph available at: [3] Notes: 1- At the moment our code relies on SkypeKit SDK [4] (a paid Skype SDK which you can get for around US$ 5) for Skype functionalities (the README file in the package explains how one can obtain SkypeKit). However, it can be easily ported to Skype public API [5], so users would not have to pay for it. 2- SkypeMorph and pluggable transports: Although our code can potentially be used as a pluggable transport, there is a minor difficulty with the pluggable transport framework that needs to be addressed before it can host our code. As mentioned above, our code uses Skype network for basic login stuff, so it takes a little bit more time than what Tor expect from a typical transport (like Obfsproxy), so the Tor client gives up building circuits after a while. We are aware of ORControllers tricks to solve the problem, but it does not seem to be the right way to do it and it would be awesome if the pluggable transport were able to tell Tor that it's working on setting up the connection, and that Tor shouldn't give up on it until it says it's ready. I am sure other transports could also benefit from this. Hooman [1]:https://blog.torproject.org/blog/obfsproxy-next-step-censorship-arms-race [2]:http://cacr.uwaterloo.ca/techreports/2012/cacr2012-08.pdf [3]:http://crysp.uwaterloo.ca/software/ [4]:http://developer.skype.com/public/skypekit [5]:http://developer.skype.com/public-api-reference

3 8

Self Introduction for GSoC 2012
by junior 06 Apr '12

06 Apr '12

Hi Tor Community, My name is Tengey Junior Patrick, a 4th year student of the University of Ghana, in Ghana of course. I am offering computer science and Mathematics and am a programmer mainly in java who is very interested in participating in GSoC 2012 with Tor. I have read that Tor is participating in GSoC 2012. I am very enthused about what Tor does and I can’t wait to be a part of this campaign of improving Internet privacy and security. Especially because I have been a victim of Internet Surveillance where my password was tempered with so I am well motivated for this. I have been observing your community interactions for some time now. I have already subscribed to the tor-announce mailing list and the tor-dev list. I have also been idling on the #tor-dev on the OFTC IRC channel. I have gone through the proposed students’ projects [2] and some documentations on "Running Tor" [1] . I have downloaded and installed the stable version of the Vidalia bundle and I am acquainting myself with its usage. I want to know if I am doing the right things since I am new to Tor. Also I want to know if the project on "Tor Controller Status Event Interface for Vidalia" is still available to work on. I particularly program in Java and have done some work on UI developements. Also I am quite proficient in the english language and can play around with photoshop as well. But I don’t really program in c++ though I have learnt the basics in skul, so does that disqualify me from working on the project. If not, what else must I know prior to the application in order to get acquainted with your practices and better understand your organizational set up. I will be very glad if help is given me in this regard. Thanks a lot. [1]https://www.torproject.org/docs/documentation.html.en [2]https://www.torproject.org/getinvolved/volunteer.html.en#Projects

2 3

Analysis of the Relative Severity of Tagging Attacks
by The23rd Raccoon 04 Apr '12

04 Apr '12

Analysis of the Relative Severity of Tagging Attacks: Hey hey, ho ho! AES-CTR mode has got to go! A cypherpunk riot brought to you by: The 23 Raccoons Abstract Gather round the dumpster, humans. It's time for your Raccoon overlords to take you to school again. Watch your step though: You don't want to catch any brain parasites[0]. Introduction For those of you who do not remember me from last time, about 4 years ago I demonstrated the effect that the Base Rate Fallacy has on timing attacks[1]. While no one has disputed the math, the applicability of my analysis to modern classifiers was questioned by George Danezis [2] and others. However, a close look at figure 5(a) of [3] shows it to be empirically correct[4]. Recently, Paul Syverson and I got into a disagreement over the effectiveness of crypto-tagging attacks such as [5]. He asked me to demonstrate that they were more powerful than active timing attacks (which I've done in [6]), and to measure just how much more powerful they were (which is shown in this work). At least I think that's what he was asking. His paragraphs were very looooooong... Anyway, out of the goodness of my little Raccoon heart, I asked my brethren to help me complete this proof ahead of schedule. We're worried about you guys. You be gettin sloppy with da attack analysis, yo (brain parasites??). And when ya get sloppy, the Raccoons pick up the scraps and multiply. And, as you'll see below, you're not gonna like it when we multiply. It means more work for you. (But you probably should have realized that in the first place). The Amplification Potential of Tagging Crypto-tagging attacks like [5] provide for an amplification attack that automatically boosts attack resource utilization by causing any uncorrelated activity to immediately fail, so the attacker doesn't have to worry about devoting resources to uncompromised traffic. Those of you who are already familiar with [5], stay with me. The authors of [5] apparently did not realize the amplification power of their attack, either. Despite my teasing above, I can see why you dismissed them initially. The crypto-tagger achieves amplification by being destructive to a circuit if the tagged cell is not untagged by them at the exit of the network, and also by being destructive when a non-tagged cell is "untagged" on a circuit coming from a non-tagging entry. It transforms all non-colluding entrances and exits into a "half-duplex global" adversary that works for the tagger to ensure that all traffic that he carries goes only through his colluding nodes. Imitating a Tagging Attack with Timing Attacks The crux of the argument against fixing crypto-tagging attacks is that they can be imitated by an active adversary using timing attacks. To imitate a tagging attack, the attacker attempts to achieve circuit killing amplification by using timing to try to determine which circuits are not flowing to colluding nodes, and kill them. The imitated tagging attack has two steps. First, the two colluding endpoints correlate all candidate matches together and kill all other circuits off. Then, they embed a more thorough active timing signature into the remaining circuits to determine the sure matches. We contend that this first step has very little timing information available due to the need to close circuits before streams are opened (which happens after just a couple cells). Certainly not enough to establish 0-error across a large sample size. Even so, in the analysis we'll be generous and concede a very low false positive rate could still be possible. It turns out not to matter that much, as long as it's non-zero. So let's analyze each step of the imitating attack in turn. Imitating Tagging: Circuit Killing Step In the first pass of the imitating attack, the adversary performs an initial correlation of new circuits, and then kills the ones that don't correlate. So let's do the base rate analysis[1] for the correlation, shall we? The probability that an arbitrary pair of circuit endpoints seen through the c/n colluding nodes belongs to the same circuit is equal to (c/n)^2 times the probability of picking an arbitrary matching pair of circuit endpoints out the network's 's' streams (1/s^2). Pk(M) = (c/n)^2 * (1/s)^2 >From my previous work in [1], we have the effect of the base rate on this attack: Pk(M|C) = Pk(C|M)*Pk(M)/(Pk(M)*Pk(C|M) + Pk(~M)*Pk(C|~M)) For every actual match, the adversary can expect to have 1/Pk(M|C) additional matches predicted by the correlater. If you churn through some more analysis, you can see that the probability Pk(~M|~C) of correctly killing non-matching circuits is pretty high (but is still a function of c/n). In other words, the adversary is pretty sure that the circuits he does kill are irrelevant. Since everyone around here likes to assume the correlating adversary is all-powerful, we doubt we need to show their strength in this avenue. Let's just assume Pk(~M|~C) = 1, and no true matches are killed early. Now for the numbers. Being a Raccoon, I am limited by the precision of my trusty rusty squirrel-skull abacus[7], so I'll give the imitating adversary several benefits of the doubt here to keep the math more simple. You can re-calculate at home on a high precision calculator without these assumptions if you like. First, let's just assume for the ease of analysis that the imitating adversary gets to behave globally in the first step and set c=n for it (relax Paul, this assumption is in your favor). After all, maybe the NSA has some tricks up their sleeve with respect to global timing analysis that we don't know about. If we don't give the imitating adversary this bonus, the base rate just gets too small to manage and crypto-tagging wins by a landslide because of its free "half-duplex global" property. It would take all of the excitement right out of our proof! Pk(M) = (n/n)^2 * (1/s)^2 = 1/s^2 To toss the imitating adversary another bone (since they keep falling off of my abacus anyway), and because a 0.0006 false positive rate "is just a non-issue"[8], we'll give those chumps an extra 0. They deserve it, they need it, and we're feeling generous. Hey, maybe they even can successfully encode some timing information between the first two cells on a circuit. Pk(C|~M) = 0.00006 Pk(C|M) = 0.99994 = 99.994% As if that weren't enough, we'll *still* use only s=5000 concurrent streams, even though over the past 4 years of network growth, that is now an absurdly low number. Pk(M) = (1/5000)^2 = 4*10^-8 Plugging everything in: Pk(M|C) = 0.99994*4*10^-8/(0.99994*4*10^-8 + (1-4*10^-8)*0.00006)) Pk(M|C) = 0.000666 1/Pk(M|C) => 1501 extra circuits survive for every true match. The imitating adversary sure seems to be carrying a lot of extra traffic at this point (roughly 1501 times as much as he wants), even though we made three seriously large (to the point of being erroneous) assumptions in his favor. Stay tuned for the exciting conclusion to see what he'll do with it. Imitating Tagging: Active Timing Attack Step (at 100% accuracy) After filtering, the imitating adversary then moves on to use an active timing attack to determine the true matches. Let's walk through the base rate analysis to see what they will look like. The probability of picking an arbitrary, random endpoint match is proportional to the number of remaining endpoints, which should trend towards the fraction of the colluding capacity times the number of total endpoints: Pi(M) ~= O((c/n) * (1/s^2)) Technically, there is a correction we need to do for the increased prior probability of matches being present due to the filtering step above, but we're going to ignore that for now, because we'll just give the adversary 100% accuracy for this stage. We do not believe a 0-error active timing attack would survive analysis (see the Future Work section), but Paul was quite insistent, and it also simplifies analysis. So here you go, Paul: Pi(C|M) = 1 Pi(C|~M) = 0 Pi(M|C) = 1*Pi(M)/(Pi(M) + 0*(1-Pi(M)) Pi(M|c) = 1 With this level of accuracy, Pi(M) is irrelevant. The base rate loses this one (but only because the error rate is contrived). Now, how many of the network's total circuits does the adversary actually compromise? Well, the adversary is carrying c/n of the network traffic, but only Pk(M|C) of those circuits are actually valid candidates for matching. Of those, Pi(M|C) are discovered by the active timing attack (all of them). Pi(compromise) = c/n * Pk(M|C) * Pi(M|C) Pi(compromise) = c/n * 0.000666 Ok, not bad. The imitating adversary seems to beat the expected O((c/n)^2) for end to end 0-error attacks for some values of c. So it might be a good idea. Sometimes. Let's check in with our crypto-tagger and see how he's doing. Full Analysis of the Crypto-Tagging Attack The most direct and intuitive route to calculate the base rate Pc(M) for the crypto-tagger is through the observation that the "half-duplex global" adversary is killing all traffic such that the all of the 's' streams that flow through the adversary's nodes are fully compromised. Pc(M) = (1 / ((c/n)*s))^2 Pc(M) = (n/c)^2 * (1/s)^2 Ugly looking base rate, but it doesn't matter, because the crypto-tagger can in fact encode arbitrary bit strings in his tags without even resorting to timing. Bit string encoding was not actually discussed in [5], but our crack research team of 23 Raccoons doesn't see why it isn't possible. Therefore, the crypto-tagger's Pc(M|C) ends up 1.0. But unlike the imitating tagger, the crypto-tagger doesn't need any gifts from Raccoons to achieve his success rate. Pc(C|M) = 1 Pc(C|~M) = 0 Pc(M|C) = 1*Pc(M)/(1*Pc(M) + 0*(1-Pc(M)) Pc(M|C) = 1 To calculate the probability of compromise of an arbitrary circuit chosen from the entire network, we need to get a measure on the number of circuits that flow through the adversary's nodes. The most direct and intuitive way to calculate this probability is to realize that the "half-duplex global" adversary created by the crypto-tag ensures that all of the c/n network capacity deployed by the attacker carries only fully compromised circuits. Therefore, the attacker can expect to compromise c/n of the circuits on the network. The probability of compromise network-wide is then: Pc(compromise) = Pc(M|C) * c/n Pc(compromise) = c/n In other words, the attack expects to compromise (c/n)*s of the network's total concurrent streams. So much for O((c/n)^2). If even just one of the major exit relays became compromised or coerced to implement a crypto-tagging attack (or hey, just did it for the lullz!), the consequences would be devastating, and invisible to users. Crypto-Tagger vs Imitating Tagger Let's compare the two probabilities of compromise: Pi(compromise) = Pc(compromise)*Pk(M|C) Pc(compromise) = Pi(compromise)/Pk(M|C) Pc(compromise) = Pi(compromise)*1501 So even with a 100% accurate active timing attack and several very liberal assumptions in favor of the imitating adversary, the crypto-tagger compromises 1501 *times* as many circuits with the same attack capacity. That's some nice amplification. Moreover, the crypto-tagger has a compromise rate of c/n, which obliterates the O((c/n)^2) expected compromise rate that c/n-carrying adversaries are supposed to be capable of compromising. Sounds like it's time to swap out AES-CTR in favor of a self-authenticating cipher[9] amirite??. OCB mode, anyone? Future work We can further elaborate the above analysis to take in more realistic error rates for active timing attacks. Such an exercise might be instructive, but we believe it is not necessary to properly evaluate imitating tagging versus crypto-tagging. It will only make the imitating tagger look worse, and everybody should realize by now he's just a poser anyway. ----------------------------- 0. https://en.wikipedia.org/wiki/Baylisascaris_procyonis 1. http://archives.seul.org/or/dev/Sep-2008/msg00016.html 2. https://conspicuouschatter.wordpress.com/2008/09/30/the-base-rate-fallacy-a… 3. http://www.cl.cam.ac.uk/~sjm217/papers/pet07ixanalysis.pdf 4. https://lists.torproject.org/pipermail/tor-talk/2012-March/023592.html 5. http://www.cs.uml.edu/~xinwenfu/paper/ICC08_Fu.pdf 6. https://www.eff.org/pages/tor-and-https 7. http://www.youtube.com/watch?v=ERwqbdAIY04 8. https://blog.torproject.org/blog/one-cell-enough 9. https://en.wikipedia.org/wiki/Authenticated_encryption 10. Look, I used more citations this time!

6 12

Gsoc 2012 Project Proposal.. Feedback please!!
by drake01 04 Apr '12

04 Apr '12

Hi guys, This is the initial proposal for "Integrating Tor with user-space transport protocol libraries" during GSOC 2012. Proposal: After initial shortlisting of transport protocols to be integrated with tor, I am left with sctp and udp. Initially I was willing to go with sctp but after getting suggestions on irc, I propose to integrate the udp library for datagram transport to tor (modified tor) as my gsoc 2012 project. I am leaving sctp (for now) and choosing UDP because: 1) I learn that testing has been done for libutp (utp) and results seem good. so risk of failure is minimized. 2) The libutp has faced the test of time and seen wide usage (u-torrent) 3) The library is already available. Although modifications will need to be done to make it work with tor.. So work from very beginning need not be done. Other stacks are also available. But It seems to be closest to what we need(based on what I know so far. Also Ref: Mentioned in the paper too: Comparison of Tor Datagram Designs.) 4) The sctp kernel space implementation has been heavily tested (as told by jmurdoch) but because of security issues mentioned in the paper of its use, sctp does not seem to be first choice to bet upon. Based on Datagram Testing Plan paper,march,2012, I would most likely fit to work on utp and hop-by-hop transport beginning in may. (I'd have no other commitment by that time.) Circuits are constructed preemptively using tcp in tor. Also since different transports are to be tested in future (possibly), So changes to be done in the tor should help it by providing a clean interface to change the protocol (sort of plugin interface.. Although the protocols are already layered to accomplish it, but reusability factor need to be taken care of as much as possible) As the hop by hop reliability is easier to implement (less changes to tor) and project of new transport protocol is new to tor, so not much experience is available. Thus as an experiment, the hop by hop reliablity seems to be the best selection right now (obviously with the scope of making changes in future) Also if the modified tor is tested on the live tor network, hop by hop reliability'll help in addressing the issue of deanonymization of nodes because major population of nodes'll be using tcp during the migration period. As mentioned in "Improving Tor using a TCP over DTLS" paper by Reardon, the implementation of DTLS (TLS for Datagram) is already there in OpenSSL. TLS and DTLS apis are unified too, i.e. same OpenSSL calls'll be able to handle sending and receiving data with minimum changes which'll have to be made to tor. I'd be extremely careful about the overall implementation so that changes done in tor don't just emerge out as a separate new branch and act as blockage for other transports and future changes. Instead, changes should be made to complement the future development. Goals to keep in mind for taking decisions while implementing: To achieve Low latency and scalability are two goals that I see to keep in mind while implementing/integrating the protocol to tor. Thorough testing is only viable option for ensuring these though. But as mentioned in the Datagram Testing Plan paper, simulation is also fine..(Please make additions here) In the end, As integrating new transport is not an individual's task to complete, its being done by a team and a plan is already there (Murdoch's march paper). So this proposal is for me to be of value to the team and not be limited to the libutp. So if time permits, I intend to help by contributing to other parts of this project too especially Experimentor. By the way, where can I find the md5 or sha digests for the Experimentor? Timeline: Google summer of code 2012 will be a 12 week (3 months) programme: I would like to report my progress twice each week preferably wednesday night (utc+0) and saturday night (again utc+0). I will submit the detailed timeline after making the proposal almost final.. I've planned to maintain a blog or github pages to provide the details about the project's progress..I would be available on irc for all of my working time though. Currently github repository for my torprojectgsoc12: https://github.com/drake01/torprojectgsoc2012 (its empty, I'll fill it soon:) ) Test code: I am planning to submit a socket based small server/client app through above repository which I wrote in initial days while learning( needs some changes to distribute though).. Also would try to write something utilising raw sockets to show my understanding of Internet Protocol stack. Comments! Current status: I have cloned the git repository of tor and a few related softwares including libutp and have it working on my machine. Also started to dissect the libutp code. I have gone through the papers, Comparison of Tor Datagram Designs and Datagram Testing Plan by Murdoch. I have overviewed the tor-design paper by Nickand Roger. Github account: https://github.com/drake01 #vim-7.3 Comments, Criticism, suggestions are most welcome.. :) -- Online pseudonym: drake01, drakeo1 or drakeoone Blog: http://goo.gl/uMnRp Github: https://github.com/drake01

3 4

Google Summer of Code Proposal - PathSupport counterpart for Stem
by Ravi Chandra Padmala 02 Apr '12

02 Apr '12

Hello I'm Ravi Chandra Padmala, a 20 year old computer programmer from India. I want to apply to the Tor Project/EFF for Google's Summer of Code program this summer. I would like to spend the summer building the PathSupport counter part for Stem. I have submitted a work in progress proposal at http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/neena/1 I've submitted a WIP proposal primarily because I need feedback on the direction my API design is taking. I have only answered question (a) from https://www.torproject.org/about/gsoc.html.en#Template . I will be updating the proposal with the rest soon. Any feedback will be greatly appreciated. -- neena

2 2

hide my site in clearweb
by Salva . 30 Mar '12

30 Mar '12

Hello, I'm going to launch a website in TOR and I dont wanna it to be visible in clearweb.So I want my site was only accessible from TOR. Anyone knows how can I do this ? Thanks.

2 1

Proposal: Integration of BridgeFinder and BridgeFinderHelper
by Mike Perry 28 Mar '12

28 Mar '12

The following proposal should complete SponsorF tickets #5010-5012. I've pushed the proposal to my torspec.git branch mikeperry/bridgefinder, since the POSTMESSAGE Proposal ended up with some garbling at somewhere along the cut and paste chain. That branch also contains fixes for the POSTMESSAGE proposal's garbling. Filename: xxx-bridgefinder-integration.txt Title: Integration of BridgeFinder and BridgeFinderHelper Author: Mike Perry Created: 18-03-2012 Status: Proposed Target: 0.2.3.x+ Overview This proposal describes how the Tor client software can interact with an external program that performs bridge discovery based on user input or information extracted from a web page, QR Code, online game, or other transmission medium. Scope and Audience This document describes how all of the components involved in bridge discovery communicate this information to the rest of the Tor software. The mechanisms of bridge discovery are not discussed, though the design aims to be generalized enough to allow arbitrary new discovery mechanisms to be added at any time. This document is also written with the hope that those who wish to implement BridgeFinder components and BridgeFinderHelpers can get started immediately after a read of this proposal, so that development of bridge discovery mechanisms can proceed in parallel to supporting functionality improvements in the Tor client software. Components and Responsibilities 0. Tor Client The Tor Client is the piece of software that connects to the Tor network (optionally using bridges) and provides a SOCKS proxy for use by the user. In initial implementations, the Tor Client will support only standard bridges. In later implementations, it is expected to support pluggable transports as defined by Proposal 180. 1. Tor Control Port The Tor Control Port provides commands to perform operations, configuration, and to obtain status information. It also optionally provides event driven status updates. In initial implementations, it will be used directly by BridgeFinder to configure bridge information via GETINFO and SETCONF. It is covered by control-spec.txt in the tor-specs git repository. In later implementations, it will support the inter-controller POSTMESSAGE IPC protocol as defined by Proposal 197 for use in conveying bridge information to the Primary Controller. 2. Primary Controller The Primary Controller is the program that launches and configures the Tor client, and monitors its status. On desktop platforms, this program is Vidalia, and it also launches the Tor Browser. On Android, this program is Orbot. Orbot does not launch a browser. On all platforms, this proposal requires that the Primary Controller will launch one or more BridgeFinder child processes and provide them with authentication information through the environment variables TOR_CONTROL_PORT and TOR_CONTROL_PASSWD. In later implementations, the Primary Controller will be expected to receive Bridge configuration information via the free-form POSTMESSAGE protocol from Proposal 197, validate that information, and hold that information for user approval. 3. BridgeFinder A BridgeFinder is a program that discovers bridges and configures Tor to use them. In initial implementations, it is likely to be very dumb, and its main purpose will be to serve as a layer of abstraction that should free the Primary Controller from having to directly implement numerous ways of retrieving bridges for various pluggable transports. In later implementations, it may perform arbitrary network operations to discover, authenticate to, and/or verify bridges, possibly using informational hints provided by one or more external BridgeFinderHelpers (see next component). It could even go so far as to download new pluggable transport plugins and/or transform definition files from arbitrary urls. It will be launched by the Primary Controller and given access to the Tor Control Port via the environment variables TOR_CONTROL_PORT and TOR_CONTROL_PASSWD. Initial control port interactions can be command driven via GETINFO and SETCONF, and do not need to subscribe to or process control port events. Later implementations will use POSTMESSAGE as defined in Proposal 197 to pass command requests to Vidalia, which will parse them and ask for user confirmation before deploying them. Use of POSTMESSAGE may or may not require event driven operation, depending on POSTMESSAGE implementation status (POSTMESSAGE is designed to support both command and event driven operation, but it is possible event driven operation will happen first). 4. BridgeFinderHelper Each BridgeFinder implementation can optionally communicate with one or more BridgeFinderHelpers. BridgeFinderHelpers are plugins to external 3rd party applications that can inspect traffic, handle mime types, or implement protocol handlers for accepting bridge discovery information to pass to BridgeFinder. Example 3rd party applications include Chrome, World of Warcraft, QR Code readers, or simple cut and paste. Due to the arbitrary nature of sandboxing that may be present in various BridgeFinderHelper host applications, we do not mandate the exact nature of the IPC between BridgeFinder instances and external BridgeFinderHelper addons. However, please see the "Security Concerns" section for common pitfalls to avoid. 5. Tor Browser This is the browser the user uses with Tor. It is not useful until Tor is properly configured to use bridges. It fails closed. It is not expected to run BridgeFinderHelper plugin instances, unless those plugin instances exist to ensure the user always has a pool of working bridges available after successfully configuring an initial bridge. Once all bridges fail, the Tor Browser is useless. 6. Non-Tor Browser (aka BridgeFinderHelper host) This is the program the user uses for normal Internet activity to obtain bridges via a BridgeFinderHelper plugin. It does not have to be a browser. In advanced scenarios, this component may not be a browser at all, but may be a program such as World of Warcraft instead. Incremental Deployability The system is designed to be incrementally deployable: Simple designs should be possible to develop and test immediately. The design is flexible enough to be easily upgraded as more advanced features become available from both Tor and new pluggable transports. Initial Implementation In the simplest possible initial implementation, BridgeFinder will only discover Tor Bridges as they are deployed today. It will use the Tor Control Port to configure these bridges directly via the SETCONF command. It may or may not receive bridge information from a BridgeFinderHelper. In an even more degenerate case, BridgeFinderHelper may even be Vidalia or Orbot itself, acting upon user input from cut and paste. Initial Implementation: BridgeFinder Launch In the initial implementation, the Primary Controller will launch one or more BridgeFinders, providing control port authentication information to them through the environment variables TOR_CONTROL_PORT and TOR_CONTROL_PASSWD. BridgeFinder will then directly connect to the control port and authenticate. Initial implementations should be able to function without using SETEVENTS, and instead only using command-based status inquiries and configuration (GETINFO and SETCONF). Initial Implementation: Obtaining Bridge Hint Information In the initial implementation, to test functionality, BridgeFinderHelper can simply scrape bridges directly from https://bridges.torproject.org. In slightly more advanced implementations, a BridgeFinderHelper instance may be written for use in the user's Non-Tor Browser. This plugin could extract bridges from images, html comments, and other material present in ad banners and slack space on unrelated pages. BridgeFinderHelper would then communicate with the appropriate BridgeFinder instance over an acceptable IPC mechanism. This proposal does not seek to specify the nature of that IPC channel (because BridgeFinderHelper may be arbitrarily constrained due to host application sandboxing), but we do make several security recommendations under the section "Security Concerns: BridgeFinder and BridgeFinderHelper". Initial Implementation: Configuring New Bridges In the initial implementation, Bridge configuration will be done directly though the control port using the SETCONF command. Initial implementations will support only retrieval and configuration of standard Tor Bridges. These are configured using SETCONF on the Tor Control Port as follows: SETCONF Bridge="IP:ORPort [fingerprint]" Future Implementations In future implementations, the system can incrementally evolve in a few different directions. As new pluggable transports are created, it is conceivable that BridgeFinder may want to download new plugin binaries (and/or new transport transform definition files) and provide them to Tor. Furthermore, it may prove simpler to deploy multiple concurrent BridgeFinder+BridgeFinderHelper pairs as opposed to adding new functionality to existing prototypes. Finally, it is desirable for BridgeFinder to obtain approval from the user before updating bridge configuration, especially for cases where BridgeFinderHelper is automatically discovering bridges in-band during Non-Tor activity. The exact mechanisms for accomplishing these improvements is described in the following subsections. Future Implementations: BridgeFinder Launch and POSTMESSAGE handshake The nature of the BridgeFinder launch and the environment variables provided is not expected to change. However, future Primary Controller implementations may decide to launch more than one BridgeFinder instance side by side. Additionally, to negotiate the IPC channel created by Proposal 197 for purposes of providing user confirmation, it is recommended that BridgeFinder and the Primary Controller perform a handshake using POSTMESSAGE upon launch, to establish that all parties properly support the feature: Primary Controller: "POSTMESSAGE @all Controller wants POSTMESSAGE v1.1" BridgeFinder: "POSTMESSAGE @all BridgeFinder has POSTMESSAGE v1.0" Primary Controller: "POSTMESSAGE @all Controller expects POSTMESSAGE v1.0" BridgeFinder: "POSTMESSAGE @all BridgeFinder will POSTMESSAGE v1.0" If this 4 step handshake proceeds with an acceptable version, BridgeFinder must use POSTMESSAGE to transmit SETCONF Bridge lines (see "Future Implementations: Configuring New Bridges" below). If POSTMESSAGE support is expected, but the handshake does not complete for any reason, BridgeFinder should either exit or go dormant. The exact nature of the version negotiation and exactly how much backwards compatibility must be tolerated is unspecified. "All-or-nothing" is a safe assumption to get started. Future Implementations: Obtaining Bridge Hint Information Future BridgeFinder implementations may download additional information based on what is provided by BridgeFinderHelper. They may fetch pluggable transport plugins, transformation parameters, and other material. Future Implementations: Configuring New Bridges Future implementations will be concerned with providing two new pieces of functionality with respect to configuring bridges: configuring pluggable transports, and properly prompting the user before altering Tor configuration. There are two ways to tell Tor clients about pluggable transports (as defined in Proposal 180). On the control port, an external Proposal 180 transport will be configured with SETCONF ClientTransportPlugin=<method> socks5 <addr:port> [auth=X] as in SETCONF ClientTransportPlugin="trebuchet socks5 127.0.0.1:9999". A managed proxy is configured with SETCONF ClientTransportPlugin=<methods> exec <path> [options] as in SETCONF ClientTransportPlugin="trebuchet exec /usr/libexec/trebuchet --managed". This example tells Tor to launch an external program to provide a socks proxy for 'trebuchet' connections. The Tor client only launches one instance of each external program with a given set of options, even if the same executable and options are listed for more than one method. Pluggable transport bridges discovered for this transport by BridgeFinder would then be set with: SETCONF Bridge="trebuchet 3.2.4.1:8080 keyid=09F911029D74E35BD84156C5635688C009F909F9 rocks=20 height=5.6m". For more information on pluggable transports and supporting Tor configuration commands, see Proposal 180. Future Implementations: POSTMESSAGE and User Confirmation Because configuring even normal bridges alone can expose the user to attacks, it is strongly desired to provide some mechanism to allow the user to approve new bridges prior to their use, especially for situations where BridgeFinderHelper is extracting them transparently while the user performs unrelated activity. If BridgeFinderHelper grows to the point where it is downloading new transform definitions or plugins, user confirmation becomes absolutely required. To achieve user confirmation, we depend upon the POSTMESSAGE command defined in Proposal 197. If the POSTMESSAGE handshake succeeds, instead of sending SETCONF commands directly to the control port, the commands will be wrapped inside a POSTMESSAGE: POSTMESSAGE @all SETCONF Bridge="www.example.com:8284" Upon receiving this POSTMESSAGE, the Primary Controller will validate it, evaluate it, store it to be later enabled by the user, and alert the user that new bridges are available for approval. It is only after the user has approved the new bridges that the Primary Controller should then re-issue the SETCONF commands to configure and deploy them in the tor client. Additionally, see "Security Concerns: Primary Controller" for more discussion on potential pitfalls with POSTMESSAGE. Security Concerns While automatic bridge discovery and configuration is quite compelling and powerful, there are several serious security concerns that warrant extreme care. We've broken them down by component. Security Concerns: Primary Controller In the initial implementation, Orbot and Vidalia must take care to transmit the Tor Control password to BridgeFinder in such a way that it does not end up in system logs, process list, or viewable by other system users. The best known strategy for doing this is by passing the information through exported environment variables. Additionally, in future implementations, Orbot and Vidalia will need to validate Proposal 197 POSTMESSAGE input before prompting the user. POSTMESSAGE is a free-form message-passing mechanism. All sorts of unexpected input may be passed through it by any other authenticated Tor Controllers for their own unrelated communication purposes. Minimal validation includes verifying that the POSTMESSAGE data is a valid Bridge or ClientTransportPlugin line and is acceptable input for SETCONF. All unexpected characters should be removed through using a whitelist, and format and structure should be checked against a regular expression. Additionally, the POSTMESSAGE string should not be passed through any string processing engines that automatically decode character escape encodings, to avoid arbitrary control port execution. At the same time, POSTMESSAGE validation should be light. While fully untrusted input is not expected due to the need for control port authentication and BridgeFinder sanitation, complicated manual string parsing techniques during validation should be avoided. Perform simple easy-to-verify whitelist-based checks, and ignore unrecognized input. Beyond POSTMESSAGE validation, the manner in which the Primary Controller achieves consent from the user is absolutely crucial to security under this scheme. A simple "OK/Cancel" dialog is insufficient to protect the user from the dangers of switching bridges and running new plugins automatically. Newly discovered bridge lines from POSTMESSAGE should be added to a disabled set that the user must navigate to as an independent window apart from any confirmation dialog. The user must then explicitly enable recently added plugins by checking them off individually. We need the user's brain to be fully engaged and aware that it is interacting with Tor during this step. If they get an "OK/Cancel" popup that interrupts their online game play, they will almost certainly simply click "OK" just to get back to the game quickly. The Primary Controller should transmit the POSTMESSAGE content to the control port only after obtaining this out-of-band approval. Security Concerns: BridgeFinder and BridgeFinderHelper The unspecified nature of the IPC channel between BridgeFinder and BridgeFinderHelper makes it difficult to make concrete security suggestions. However, from past experience, the following best practices must be employed to avoid security vulnerabilities: 1. Define a non-webby handshake and/or perform authentication The biggest risk is that unexpected applications will be manipulated into posting malformed data to the BridgeFinder's IPC channel as if it were from BridgeFinderHelper. The best way to defend against this is to require a handshake to properly complete before accepting input. If the handshake fails at any point, the IPC channel must be abandoned and closed. Do not continue scanning for good input after any bad input has been encountered. Additionally, if possible, it is wise to establish a shared secret between BridgeFinder and BridgeFinderHelper through the filesystem or any other means available for use in authentication. For an a good example on how to use such a shared secret properly for authentication, see Trac Ticket #5185 and/or the SafeCookie Tor Control Port authentication mechanism. 2. Perform validation before parsing Care must be taken before converting BridgeFinderHelper data into Bridge lines, especially for cases where the BridgeFinderHelper data is fed directly to the control port after passing through BridgeFinder. The input should be subjected to a character whitelist and possibly also validated against a regular expression to verify format, and if any unexpected or poorly-formed data is encountered, the IPC channel must be closed. 3. Fail closed on unexpected input If the handshake fails, or if any other part of the BridgeFinderHelper input is invalid, the IPC channel must be abandoned and closed. Do *not* continue scanning for good input after any bad input has been encountered. -- Mike Perry

4 12

Improving Tor Hidden Services
by Arturo Filastò 27 Mar '12

27 Mar '12

Setting aside the issue related with usability there are also some interesting improvements that can be made to make Tor HS more performant. I will summarize here the ideas that have been brought forward along with some that are not detailed anywhere and would like to see more interest in. I would suggest to start collecting all the information regarded to Tor HS improvements on this wiki page: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/HiddenServic…. With respect to what is already on that page I got some feedback from rransom on those two items on IRC, but I did not note them down. It would be good if you were to summarize the critiques here or on the wiki page. Also there are a set of proposals that are related to Tor HS improvements that have been abandoned for some time and I believe it would be useful to summarize them inside of that wiki page. The proposals are: #121 Filename: 121-hidden-service-authentication.txt Title: Hidden Service Authentication https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/121-hidden-s… #142 Filename: 142-combine-intro-and-rend-points.txt Title: Combine Introduction and Rendezvous Points https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/142-combine-… #143 Filename: 143-distributed-storage-improvements.txt Title: Improvements of Distributed Storage for Tor Hidden Service Descriptors https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/143-distribu… #155 Filename: 155-four-hidden-service-improvements.txt Title: Four Improvements of Hidden Service Performance https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/155-four-hid… #194 Filename: 194-mnemonic-urls.txt Title: Mnemonic .onion URLs https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/194-mnemonic… and also this inside of the ideas, that is loosely related to #194, but instead of offering an encoding it offers a petname system: Filename: xxx-onion-nyms.txt Title: .onion nym system https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-on… The single most important thing I believe is needed in Tor Hidden Service is Encrypted services. These can be seen, in a way, as the reverse of Tor2web mode. It allows people to publish Hidden Services with no anonymity, but have the Tor end-to-end encryption and performance improvements. I see these to be the future of what was previously done, poorly, with Tor Exit Enclaves. One that wishes to have an end-to-end encrypted tunnel from Tor clients can run an encrypted service and have a reduced number of hops from the IP and RP. Roger started writing up a spec on this and it can be found here: Filename: xxx-encrypted-services.txt Title: Encrypted services as a replacement to exit enclaving https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-en… - Art.

2 1

Implement JSONP interface for check.torproject.org
by Arturo Filastò 26 Mar '12

26 Mar '12

I have made a patch to check.torproject.org to expose a JSONP interface that would allow people to have the user check client side if (s)he is using Tor. This would allow people to embed a badge on their website (privacybadge.html) that congratulates the user of using Tor or warns him of non Tor usage with a link to torproject.org. I can imagine privacy advocates having this deployed on their websites or systems that engourage users to connect to them anonymously. Compared to what check.torproject.org does at the moment the risk does not change, it is erogating exactly the same service, just making it more useful and flexible. Basically what it does is check if the ip doing the connection is connected through Tor. The web service will reply with a JSON encoded array that can be loaded from the user and display in the browser a nice looking badge. You can see how this works on the live demo hosted here: http://hellais.github.com/torcheck/privacybadge.html I still need to finish the styling of the badge to contain links to torproject.org and generally make it cooler. Also, the check.torproject repo should be moved to svn. - Art.

4 10

Proposal 198: Restore semantics of TLS ClientHello
by Nick Mathewson 26 Mar '12

26 Mar '12

Filename: 198-restore-clienthello-semantics.txt Title: Restore semantics of TLS ClientHello Author: Nick Mathewson Created: 19-Mar-2012 Status: Open Overview: Currently, all supported Tor versions try to imitate an older version of Firefox when advertising ciphers in their TLS ClientHello. This feature is intended to make it harder for a censor to distinguish a Tor client from other TLS traffic. Unfortunately, it makes the contents of the ClientHello unreliable: a server cannot conclude that a cipher is really supported by a Tor client simply because it is advertised in the ClientHello. This proposal suggests an approach for restoring sanity to our use of ClientHello, so that we still avoid ciphersuite-based fingerprinting, but allow nodes to negotiate better ciphersuites than they are allowed to negotiate today. Background reading: Section 2 of tor-spec.txt 2 describes our current baroque link negotiation scheme. Proposals 176 and 184 describe more information about how it got that way. Bug 4744 is a big part of the motivation for this proposal: we want to allow Tors to advertise even more ciphers, some of which we would actually prefer to the ones we are using now. What you need to know about the TLS handshake is that the client sends a list of all the ciphersuites that it supports in its ClientHello message, and then the server chooses one and tells the client which one it picked. Motivation and constraints: We'd like to use some of the ECDHE TLS ciphersuites, since they allow us to get better forward-secrecy at lower cost than our current DH-1024 usage. But right now, we can't ever use them, since Tor will advertise them whether or not it has a version of OpenSSL that supports them. (OpenSSL before 1.0.0 did not support ECDHE ciphersuites; OpenSSL before 1.0.0e or so had some security issues with them.) We cannot have the rule be "Tors must only advertise ciphersuites that they can use", since current Tors will advertise such ciphersuites anyway. We cannot have the rule be "Tors must support every ECDHE ciphersuite on the following list", since current Tors don't do all that, and since one prominent Linux distribution builds OpenSSL without ECC support because of patent/freedom fears. Fortunately, nearly every ciphersuite that we would like to advertise to imitate FF8 (see bug 4744) is currently supported by OpenSSL 1.0.0 and later. This enables the following proposal to work: Proposed spec changes: I propose that the rules for handling ciphersuites at the server side become the following: If the ciphersuites in the ClientHello contains no ciphers other than the following[*], they indicate that the Tor v1 link protocol is in use. TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA If the advertised ciphersuites in the ClientHello are _exactly_[*] the following, they indicate that the Tor v2+ link protocol is in use, AND that the ClientHello may have unsupported ciphers. In this case, the server may choose DHE_RSA_WITH_AES_128_CBC_SHA or DHE_RSA_WITH_AES_256_SHA, but may not choose any other cipher. TLS1_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS1_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS1_DHE_RSA_WITH_AES_256_SHA TLS1_DHE_DSS_WITH_AES_256_SHA TLS1_ECDH_RSA_WITH_AES_256_CBC_SHA TLS1_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS1_RSA_WITH_AES_256_SHA TLS1_ECDHE_ECDSA_WITH_RC4_128_SHA TLS1_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS1_ECDHE_RSA_WITH_RC4_128_SHA TLS1_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS1_DHE_RSA_WITH_AES_128_SHA TLS1_DHE_DSS_WITH_AES_128_SHA TLS1_ECDH_RSA_WITH_RC4_128_SHA TLS1_ECDH_RSA_WITH_AES_128_CBC_SHA TLS1_ECDH_ECDSA_WITH_RC4_128_SHA TLS1_ECDH_ECDSA_WITH_AES_128_CBC_SHA SSL3_RSA_RC4_128_MD5 SSL3_RSA_RC4_128_SHA TLS1_RSA_WITH_AES_128_SHA TLS1_ECDHE_ECDSA_WITH_DES_192_CBC3_SHA TLS1_ECDHE_RSA_WITH_DES_192_CBC3_SHA SSL3_EDH_RSA_DES_192_CBC3_SHA SSL3_EDH_DSS_DES_192_CBC3_SHA TLS1_ECDH_RSA_WITH_DES_192_CBC3_SHA TLS1_ECDH_ECDSA_WITH_DES_192_CBC3_SHA SSL3_RSA_FIPS_WITH_3DES_EDE_CBC_SHA SSL3_RSA_DES_192_CBC3_SHA [*] The "extended renegotiation is supported" ciphersuite, 0x00ff, is not counted when checking the list of ciphersuites. Otherwise, the ClientHello has these semantics: The inclusion of any cipher supported by OpenSSL 1.0.0 means that the client supports it, with the exception of SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA which is never supported. Clients MUST advertise support for at least one of TLS_DHE_RSA_WITH_AES_256_CBC_SHA or TLS_DHE_RSA_WITH_AES_128_CBC_SHA. The server MUST choose a ciphersuite with ephemeral keys for forward secrecy; MUST NOT choose a weak or null ciphersuite; and SHOULD NOT choose any cipher other than AES or 3DES. Discussion and consequences: Currently, OpenSSL 1.0.0 (in its default configuration) supports every cipher that we would need in order to give the same list as Firefox versions 8 through 11 give in their default configuration, with the exception of the FIPS ciphersuite above. Therefore, we will be able to fake the new ciphersuite list correctly in all of our bundles that include OpenSSL, and on every version of Unix that keeps up-to-date. However, versions of Tor compiled to use older versions of OpenSSL, or versions of OpenSSL with some ciphersuites disabled, will no longer give the same ciphersuite lists as other versions of Tor. On these platforms, Tor clients will no longer impersonate Firefox. Users who need to do so will have to download one of our bundles, or use a (non-system) OpenSSL. The proposed spec change above tries to future-proof ourselves by not declaring that we support every declared cipher, in case we someday need to handle a new Firefox version. If a new Firefox version comes out that uses ciphers not supported by OpenSSL 1.0.0, we will need to define whether clients may advertise its ciphers without supporting them; but existing servers will continue working whether we decide yes or no. The restriction to "servers SHOULD only pick AES or 3DES" is meant to reflect our current behavior, not to represent a permanent refusal to support other ciphers. We can revisit it later as appropriate, if for some bizarre reason Camellia or Seed or Aria becomes a better bet than AES. Open questions: Should the client drop connections if the server chooses a bad cipher, or a suite without forward secrecy? Can we get OpenSSL to support the dubious FIPS suite excluded above, in order to remove a distinguishing opportunity? It is not so simple as just editing the SSL_CIPHER list in s3_lib.c, since the nonstandard SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA cipher is (IIUC) defined to use the TLS1 KDF, while declaring itself to be an SSL cipher (!). Can we do anything to eventually allow the IE7+[**] cipher list as well? IE does not support TLS_DHE_RSA_WITH_AES_{256,128}_SHA or SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and so wouldn't work with current Tor servers, which _only_ support those. It looks like the only forward-secure ciphersuites that IE7+ *does* support are ECDHE ones, and DHE+DSS ones. So if we want this flexibility, we could mandate server-side ECDHE, or somehow get DHE+DSS support (which would play havoc with our current certificate generation code IIUC), or say that it is sometimes acceptable to have a non-forward-secure link protocol[***]. None of these answers seems like a great one. Is one best? Are there other options? [**] Actually, I think it's the Windows SChannel cipher list we should be looking at here. [***] If we did _that_, we'd want to specify that CREATE_FAST could never be used on a non-forward-secure link. Even so, I don't like the implications of leaking cell types and circuit IDs to a future compromise.

5 7