- 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

Missing methodname in proposal 180 example
by David Fifield 26 Mar '12

26 Mar '12

I found a little typo in proposal 180. David Fifield

2 1

Self publishing over Tor Hidden Services
by Arturo Filastò 25 Mar '12

25 Mar '12

Tor Hidden Services are great, though their impact is grossly limited by the fact that they are not at all easy to deploy. Systems such as Tor2web allow people that decide to publish anonymously to be reachable by anybody not using a Tor client. For dealing with the usability aspect of Tor Hidden Services, this GSoC I am going to be mentoring APAF: Anonymous Python Application Framework. The goal is to give easy to use tools for people to do self publishing. This is a basic description of the project: 1. Overview Tor Hidden Services are underused compared to their potential, the goal of APAF is to provide an easy system to allow network related python application developers to build their software in a way that it runs as a Tor Hidden Service (Tor HS). The framework will allow developers to easily build .exe, .app, statically linked linux binaries that contain the python interpreter and the Tor daemon. This will allow the end user to easily start running that service on their machine, by simply downloading a package. This is similar to what is done with the Tor Browser Bundle (TBB). 2. Motivation One of the reasons for which Tor HS are not used that much is that there is no simple way for an application developer to ship their application with a Tor binary and automatically configure a Tor HS. This leads to users not being able to easily run Tor Hidden Services on their desktop machines limiting the diffusion of HSs. An example use case is a person that wishes to run a temporary chat server on their home machine. With APAF a chat server developer could package such a python application and the end user will be able to run it by downloading a package and executing it. 3. What is built? APAF compiles all the dependencies for all the target systems. The software that will come bundled with it are: * the Python interpreter (cpython bundled with PyInstaller: http://www.pyinstaller.org/) * Tor * The desired python dependecies (computed with PyInstaller) The build system must be configurable and extensible. It should allow easy bundling of third party applications such as p7zip, gpg, etc as APAF modules, in order to let the project grow with new functionalities. The output of the build process will be: - Win32: MyApplication.exe - OSX: MyApplication.app (inside an Application.dmg container) - Linux: Deb build or statically linked binary The buildsystem should download the latest release of Tor for the appropriate platform and extract the required files into the build structure, in order to be packaged within the application. Note: Another possibility is that it could build Tor from source for the desired target platforms, but this may require some additional effort. 4. What happens when I start APAF? When APAF starts the user running it is presented with a splash screen that displays the startup progress. The image in the splash screen should be customizable by the application developer. Another option would be to start the system browser and point it to http://127.0.0.1:<APAF_port>/ and display the bootstrap process inside of the bundled web based UI. At first launch APAF will show a startup splash screen with a progress bar describing application startup event informations, optionally displaying an image. Then the system browser will be started to let the user access APAF UI, that will provide a wizard for bootstrapping the setup of the Tor Hidden Service. If the APAF application is already running by clicking on it, it will just start the browser to open directly the APAF UI. By default APAF will come with a web application that is used for administering and checking on the status of the running Tor HS. It should provide functionality the following functionality: * Check the current status of the Tor HS (it's hostname and port mapping) * Start and stop tor Hidden Service * API to add/remove new Tor Hidden service mapping * Select from the list of bundled applications the ones to run * Test it's reachability from the Tor network (by doing a request over Tor to it's .onion address) * Configure Tor (User Interface to edit torrc) * Close Awaf 5. Web Applications One of the first applications that will be used as an example for APAF will be a simple python web application. The application will simply serve to the client static files. The basic scaffolding that this web application provides should allow developers to build their own web application based on this example. The application will be written using TornadoWeb (http://www.tornadoweb.org/) 6. Security Features Outbound Connection Torrification --------------------------------- The framework must provide support to automatically torify all or specific outbound connection. The entire python application framework (Tornadoweb) should be forbidden to make any outbound connections directly, it should not leak out of the Tor network. Inbound Connection (Tor Hidden Service) --------------------------------------- APAF will expose to the Tor network the configured Tor Hidden Service running the bundled server software. The user will be able to properly configure their HS and choose if to allow connections from tor2web (in the case of a web application) or not. Misc. ---- Ideally the application should come with security enhancements such as sandboxing and hardening of the system to minimize anonymity leaks and security vulnerability exploitability. 7. Documentation APAF must provide detailed documentation on: - how to setup the build environment (eventually on multiple operating systems) - how to customize your own enviroment for your own anonymous web application - any specific documentation on particular procedures and/or internal structure - user manual for running an APAF built application Specific to Google Summer of Code the student will complete the following: For GSoC the student is expected to create the build system capable of building a simple web application that serves static files. It should also include a web UI for a wizard setup, checking the status of the HS and configuring it. I believe this project has some common goals with the work TAILS wants to do on the "TAILS server edition" [1]. I would be very interested in having feedback on this topic to manage to properly set the scope of the tasks to be done during GSoC. maker is interested in working on this project and we have been discussing it with him in the past days. - Art. [1] tails.boum.org/todo/server_edition/

2 1

Re: [tor-dev] Proposal 193: Safe cookie authentication
by Robert Ransom 22 Mar '12

22 Mar '12

I've pushed a revised protocol change to branch safecookie of git.tpo/rransom/torspec.git, and a (messy, needs rebase, untested) implementation to branch safecookie-023 of git.tpo/rransom/tor.git. Now, the client and server nonces are fed to the same HMAC invocation, so that the client can believe (modulo Merkle-Damgard and general iterative hash function ‘features’) that the server knows the cookie (rather than just HMAC(constant, cookie)). Almost all controllers must drop almost all support for non-safe cookie authentication ASAP, because a compromised system-wide Tor process could drop a symlink to /home/rransom/.ed25519-secret-key in where it was supposed to put a cookie file. The sole exception to ‘non-safe cookie authentication must die’ is when a controller knows that it is connected to a server process with equal or greater access to the same filesystem it has access to. In practice, this means ‘only if you're completely sure that Tor is running in the same user account as the controller, and you're completely sure that you're connected to Tor’, and no controller is sure of either of those. Robert Ransom

2 2

Proposal 200: Adding new, extensible CREATE, EXTEND, and related cells
by Nick Mathewson 22 Mar '12

22 Mar '12

Filename: 200-new-create-and-extend-cells.txt Title: Adding new, extensible CREATE, EXTEND, and related cells Author: Robert Ransom Created: 2012-03-22 Status: Open History The original draft of this proposal was from 2010-12-27; nickm revised it slightly on 2012-03-22 and added it as proposal 200. Overview and Motivation: In Tor's current circuit protocol, every field, including the 'onion skin', in the EXTEND relay cell has a fixed meaning and length. This prevents us from extending the current EXTEND cell to support IPv6 relays, efficient UDP-based link protocols, larger 'onion keys', new circuit-extension handshake protocols, or larger identity-key fingerprints. We will need to support all of these extensions in the near future. This proposal specifies a replacement EXTEND2 cell and related cells that provide more room for future extension. Design: FIXME - allocate command ID numbers (non-RELAY commands for CREATE2 and CREATED2; RELAY commands for EXTEND2 and EXTENDED2) The CREATE2 cell contains the following payload: Handshake type [2 bytes] Handshake data length [2 bytes] Handshake data [variable] The relay payload for an EXTEND2 relay cell contains the following payload: Number of link specifiers [1 byte] N times: Link specifier type [1 byte] Link specifier length [1 byte] Link specifier [variable] Handshake type [2 bytes] Handshake data length [2 bytes] Handshake data [variable] The CREATED2 cell and EXTENDED2 relay cell both contain the following payload: Handshake data length [2 bytes] Handshake data [variable] All four cell types are padded to 512-byte cells. When a relay X receives an EXTEND2 relay cell: * X finds or opens a link to the relay Y using the link target specifiers in the EXTEND2 relay cell; if X fails to open a link, it replies with a TRUNCATED relay cell. (FIXME: what do we do now?) * X copies the handshake type and data into a CREATE2 cell and sends it along the link to Y. * If the handshake data is valid, Y replies by sending a CREATED2 cell along the link to X; otherwise, Y replies with a TRUNCATED relay cell. (XXX: we currently use a DESTROY cell?) * X copies the contents of the CREATED2 cell into an EXTENDED2 relay cell and sends it along the circuit to the OP. Link target specifiers: The list of link target specifiers must include at least one address and at least one identity fingerprint, in a format that the extending node is known to recognize. The extending node MUST NOT accept the connection unless at least one identity matches, and should follow the current rules for making sure that addresses match. [00] TLS-over-TCP, IPv4 address A four-byte IPv4 address plus two-byte ORPort [01] TLS-over-TCP, IPv6 address A sixteen-byte IPv6 address plus two-byte ORPort [02] Legacy identity A 20-byte SHA1 identity fingerprint. At most one may be listed. As always, values are sent in network (big-endian) order. Legacy handshake type: The current "onionskin" handshake type is defined to be handshake type [00 00], or "legacy". The first (client->relay) message in a handshake of type “legacy” contains the following data: ‘Onion skin’ (as in CREATE cell) [DH_LEN+KEY_LEN+PK_PAD_LEN bytes] This value is generated and processed as sections 5.1 and 5.2 of tor-spec.txt specify for the current CREATE cell. The second (relay->client) message in a handshake of type “legacy” contains the following data: Relay DH public key [DH_LEN bytes] KH (see section 5.2 of tor-spec.txt) [HASH_LEN bytes] These values are generated and processed as sections 5.1 and 5.2 of tor-spec.txt specify for the current CREATED cell. After successfully completing a handshake of type “legacy”, the client and relay use the current relay cryptography protocol. Bugs: This specification does not accommodate: * circuit-extension handshakes requiring more than one round No circuit-extension handshake should ever require more than one round (i.e. more than one message from the client and one reply from the relay). We can easily extend the protocol to handle this, but we will never need to. * circuit-extension handshakes in which either message cannot fit in a single 512-byte cell along with the other required fields This can be handled by specifying a dummy handshake type whose data (sent from the client) consists of another handshake type and the beginning of the data required by that handshake type, and then using several (newly defined) HANDSHAKE_COMPLETION relay cells sent in each direction to transport the remaining handshake data. The specification of a HANDSHAKE_COMPLETION relay cell and its associated dummy handshake type can safely be postponed until we develop a circuit-extension handshake protocol that would require it. * link target specifiers that cause EXTEND2 cells to exceed 512 bytes This can be handled by specifying a LONG_COMMAND relay cell type that can be used to transport a large ‘virtual cell’ in multiple 512-byte cells. The specification of a LONG_COMMAND relay cell can safely be postponed until we develop a link target specifier, a RELAY_BEGIN2 relay cell and stream target specifier, or some other relay cell type that would require it.

1 0

Tor for iOS via official channels
by Linas Valiukas 21 Mar '12

21 Mar '12

Hello, I was thinking about a GSoC 2012 project I could propose, and I came to the question of why there's no Tor iOS (iPhone / iPad / iPod touch) application distributed on the official iTunes App Store? There's this "test package" of Tor for iOS available [1], but it has to be installed via Cydia and not everyone's phone is jailbroken. Distributing an application via the App Store has some benefits of its own too (additional marketing and visibility, easier installation, to name a few). So, what is the problem? * Would it comply with the iOS Developer Program License Agreement? I'm no lawyer, but last I read the document there's nothing in it that would prevent distributing an app which would create a "local" HTTP proxy to be used by the other applications. * Since the iPhone 3GS, the applications can retain running in the background, so I guess we're fine on the purely technical side too. * There are US Export laws that require a so-called CCATS review and approval to be done with each application that employs strong encryption. I don't think that's a blocker though. * Maybe that Tor iOS application wouldn't reach various "interesting" markets such as PRC (for example, a commercial yet pricy "Covert Browser" [2] is not available in China's App Store) because of the legal restrictions. Still, I would argue that it is worth having such an application. Regards, [1]: http://sid77.slackware.it/ios/ [2]: http://itunes.apple.com/us/app/covert-browser/id477438328?mt=8 -- Linas Valiukas +370 687 65870 www.pypt.lt

5 6

Re: [tor-dev] Proposal 198: Restore semantics of TLS ClientHello
by Jacob Appelbaum 21 Mar '12

21 Mar '12

On 03/20/2012 09:08 PM, Nick Mathewson wrote: > On Tue, Mar 20, 2012 at 11:57 PM, Jacob Appelbaum <jacob(a)appelbaum.net> wrote: > [...] >> Ah ha. That sounds like a nightmare. Is there a bug report we can pile >> on to request that they don't create a headache for everyone in the future? > > There is, but I don't currently see much point: their developers are > irritated, and know that other developers are irritated, and believe > that they can't take any actual action without word from their legal > department. > We can provide packages for users or a spec file for their users as an alternative, I guess? I think generally we're already doing this by providing the Tor Browser but all users with system tors are going to be left out... >>>> It seems that our integration with >>>> platforms is really heading in a bad direction. I'd like to figure out >>>> how to not diverge entirely and if possible to fix or document the issues. >>> >>> I don't know what you mean by "diverge" here -- do you mean that >>> different platforms may advertise different ciphers based on their >>> version of OpenSSL or whether their legal department fears ECC? If >>> so, then all non-Tor OpenSSL applications running on those hosts >>> already leak this information. >> >> I mean - Tor's cipher suite advertisement will be really wacky, >> basically on a platform by platform basis, version by version basis. >> What we expect to say about tor's fingerprint is less and less easy to >> say concisely, or perhaps it's easy but has a few variants? It seems >> like we'll have to track it more closely, perhaps by sniffing network >> traces on a per OS basis? > > It should be fairly easy to notice what ciphers we are really > advertising, and warn when it isn't the list we want to advertise. > Sure, it's just a simple matter of programming. ;-) > What we can expect to say about the fingerprint will be: "If you have > a default build of OpenSSL 1.0.0 or later, then you will look like > Firefox 8+ (modulo other issues not related to ciphersuites). If you > have an ECC-disabled build of OpenSSL 1.0.0 or later, then you will > look like FF8+ with all the ECC turned off. (I am pretty sure that > Fedora does indeed turn off the ECC in the Firefox they ship.) > Otherwise, if you have a really weird OpenSSL build, or an older > version of OpenSSL, your fingerprint will be weird." > I think that's a lot of stuff to say - we'll probably want to keep track of our various fingerprints somewhere - a bug or the wiki, perhaps? > [...] >> My thought was as follows - we have a >> pt_client{many-cipher-suites-support} that can be made to impersonate >> many browsers, it can try to connect to either relays which it can thus >> become Firefox without issue or to a bridge with this >> pt_server{many-cipher-suites-support} support and so it can pretend to >> be nearly anything. I probably should have made that suggestion more >> explicit. >> >> But yes, I agree, unless we can make the servers support the required >> ciphers, I think we're doomed. I didn't miss that, I was just trying to >> suggest a hack whereby we can impersonate IE as a pluggable transport. >> >> I've wondered for a while about cipher suites, specifically, why can't >> we just lie on the wire and then internally map ciphers as we like? For >> example - our client sends ECDHE but our server understands this is us >> trying as a client to impersonate IE and maps that to some other forward >> secret cipher suite like TLS_DHE_RSA_WITH_AES_128_SHA? I'm sure it's a >> TLS nightmare but, I guess it feels like we're heading there anyway...? > > Actually, we are heading AWAY from the TLS nightmare. That's the point > of this proposal: to minimize our use of ClientHello ciphersuite > fakery, so that the TLS ciphersuite negotiation handshake can > eventually just work again. > Well, OK, I think I understand that. Sorta. I agree that it is a step in the right direction but I do think it's a nightmare unless we have some way to basically make tor perform uniformly without us tracking things. Basically, we can impersonate a few browsers on the client side but the relays limit our ability to impersonate properly. It seems like a lot of stuff to keep track up, I already want a lookup table to know which version of tor, which version of openssl, which platform, etc to know what my handshake looks like and so on. It's not that complicated, it's just complicated enough though... > The idea above wouldn't work in any straightforward way: It is easy to > tell a DHE handshake from an ECDHE handshake -- for example, by > looking at the group parameters, which are sent in the clear! -- so if > the server says that it picks one but then the server and the client > do another, that would be really easy to detect. Ok, I admit, I had no idea that the group parameters were sent in the clear - I agree, just hacking up the cipher suites isn't actually useful in that case. Argh! All the best, Jake

1 0

Re: [tor-dev] Proposal 198: Restore semantics of TLS ClientHello
by Nick Mathewson 21 Mar '12

21 Mar '12

Jacob sent me this message in reply to my last; sending to tor-dev with permission. On Tue, Mar 20, 2012 at 11:57 PM, Jacob Appelbaum <jacob(a)appelbaum.net> wrote: > On 03/20/2012 08:14 PM, Nick Mathewson wrote: >> On Tue, Mar 20, 2012 at 9:30 PM, Jacob Appelbaum <jacob(a)appelbaum.net> wrote: >>> On 03/20/2012 08:33 AM, Nick Mathewson wrote: >>>> Filename: 198-restore-clienthello-semantics.txt >>>> Title: Restore semantics of TLS ClientHello >>>> Author: Nick Mathewson >>>> Created: 19-Mar-2012 >>>> Status: Open >>>> >>> >>> [ ... ] >>> >>> >>>> 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. >>>> >>> >>> What platforms have this issue? >> >> The ones that don't have OpenSSL 1.0.0, and the ones that turn off >> some of the relevant ciphersuites in OpenSSL 1.0.0. > > > Sure, I understand the pre-OpenSSL 1.0.0 issue - I mostly wondered what > platforms don't support the relevant ciphersuites in their builds of > OpenSSL 1.0.0. We should either 0) file bug reports 1) offer packages > that fix the issue or 2) something else such as ignoring it and simply > tracking the issues. > >> >> With time, the number of platforms that don't ship 1.0.0 or later will >> fall. Furthermore, we can support them just fine with a TBB that >> includes OpenSSL. >> > > Sure. That makes sense. The main downside is that TBB is a UX nightmare. > It works OK for browsing and basically everything else becomes ten times > the nightmare. > >> To the best of my knowledge, Fedora is the only major OS that ships >> OpenSSL and turns off any of the ciphersuites we care about, though >> there could be more. Last I heard, their legal department were >> reviewing that decision. >> > > Ah ha. That sounds like a nightmare. Is there a bug report we can pile > on to request that they don't create a headache for everyone in the future? > >>> It seems that our integration with >>> platforms is really heading in a bad direction. I'd like to figure out >>> how to not diverge entirely and if possible to fix or document the issues. >> >> I don't know what you mean by "diverge" here -- do you mean that >> different platforms may advertise different ciphers based on their >> version of OpenSSL or whether their legal department fears ECC? If >> so, then all non-Tor OpenSSL applications running on those hosts >> already leak this information. > > I mean - Tor's cipher suite advertisement will be really wacky, > basically on a platform by platform basis, version by version basis. > What we expect to say about tor's fingerprint is less and less easy to > say concisely, or perhaps it's easy but has a few variants? It seems > like we'll have to track it more closely, perhaps by sniffing network > traces on a per OS basis? >> >> But in any case, I think that the damage is self-healing (as people >> upgrade to OpenSSL 1.0.0) and the alternative of being stuck on our >> current ciphersuites forever is worse. >> > > Ok. That I find pretty convincing. > >>>> Open questions: >>>> >>>> Should the client drop connections if the server chooses a bad >>>> cipher, or a suite without forward secrecy? >>>> >>> >>> I think so. Do we have any relays that do not currently support forward >>> secrecy? >> >> No. >> > > Ok. > >> The question is, what should a client do if the relay selects, say, >> TLS_RSA_AES_128_CBC_SHA1 (ciphersuite name may not be exact). If it >> drops the connection immediately, that might be unusual behavior. >> Some other behavior might be smarter: perhaps it should pause for a >> while, then drop. Or perhaps it should send a little junk data then >> drop. I'm not sure there, though. > > Ah. What does s_client do if that selected cipher is not supported? When > in doubt, I often just punt and do what s_client does... > >> >> [...] >>>> 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? >>>> >>> >>> This sounds like a job for pluggable transports! >>> >>> I think as long as the servers support as many ciphers as possible, we >>> can make simple pluggable transports that setup the cipher suites we >>> want to use - no? >> >> Pluggable transports feel out-of-scope for this proposal. But even if >> they are, I don't see how they answer my question: Because (as a >> given!) current servers do not support any of the forward-secure >> ciphers on the IE7 list, if we want to impersonate IE7 or later, we >> will be doing something that current servers cannot support. Whether >> this impersonation is done somehow as a plugin, or in Tor, it would >> still be something we needed to coordinate with the servers in >> question. >> > > My thought was as follows - we have a > pt_client{many-cipher-suites-support} that can be made to impersonate > many browsers, it can try to connect to either relays which it can thus > become Firefox without issue or to a bridge with this > pt_server{many-cipher-suites-support} support and so it can pretend to > be nearly anything. I probably should have made that suggestion more > explicit. > > But yes, I agree, unless we can make the servers support the required > ciphers, I think we're doomed. I didn't miss that, I was just trying to > suggest a hack whereby we can impersonate IE as a pluggable transport. > > I've wondered for a while about cipher suites, specifically, why can't > we just lie on the wire and then internally map ciphers as we like? For > example - our client sends ECDHE but our server understands this is us > trying as a client to impersonate IE and maps that to some other forward > secret cipher suite like TLS_DHE_RSA_WITH_AES_128_SHA? I'm sure it's a > TLS nightmare but, I guess it feels like we're heading there anyway...? > > (I'm sorry if this seems rambly, I've been pretty sick...) > > All the best, > Jake

1 1

Re: [tor-dev] Proposal 198: Restore semantics of TLS ClientHello
by Nick Mathewson 21 Mar '12

21 Mar '12

Forgot to send this to tor-dev: ouch. Sending now. On Tue, Mar 20, 2012 at 9:30 PM, Jacob Appelbaum <jacob(a)appelbaum.net> wrote: > On 03/20/2012 08:33 AM, Nick Mathewson wrote: >> Filename: 198-restore-clienthello-semantics.txt >> Title: Restore semantics of TLS ClientHello >> Author: Nick Mathewson >> Created: 19-Mar-2012 >> Status: Open >> > > [ ... ] > > >> 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. >> > > What platforms have this issue? The ones that don't have OpenSSL 1.0.0, and the ones that turn off some of the relevant ciphersuites in OpenSSL 1.0.0. With time, the number of platforms that don't ship 1.0.0 or later will fall. Furthermore, we can support them just fine with a TBB that includes OpenSSL. To the best of my knowledge, Fedora is the only major OS that ships OpenSSL and turns off any of the ciphersuites we care about, though there could be more. Last I heard, their legal department were reviewing that decision. > It seems that our integration with > platforms is really heading in a bad direction. I'd like to figure out > how to not diverge entirely and if possible to fix or document the issues. I don't know what you mean by "diverge" here -- do you mean that different platforms may advertise different ciphers based on their version of OpenSSL or whether their legal department fears ECC? If so, then all non-Tor OpenSSL applications running on those hosts already leak this information. But in any case, I think that the damage is self-healing (as people upgrade to OpenSSL 1.0.0) and the alternative of being stuck on our current ciphersuites forever is worse. >> Open questions: >> >> Should the client drop connections if the server chooses a bad >> cipher, or a suite without forward secrecy? >> > > I think so. Do we have any relays that do not currently support forward > secrecy? No. The question is, what should a client do if the relay selects, say, TLS_RSA_AES_128_CBC_SHA1 (ciphersuite name may not be exact). If it drops the connection immediately, that might be unusual behavior. Some other behavior might be smarter: perhaps it should pause for a while, then drop. Or perhaps it should send a little junk data then drop. I'm not sure there, though. [...] >> 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? >> > > This sounds like a job for pluggable transports! > > I think as long as the servers support as many ciphers as possible, we > can make simple pluggable transports that setup the cipher suites we > want to use - no? Pluggable transports feel out-of-scope for this proposal. But even if they are, I don't see how they answer my question: Because (as a given!) current servers do not support any of the forward-secure ciphers on the IE7 list, if we want to impersonate IE7 or later, we will be doing something that current servers cannot support. Whether this impersonation is done somehow as a plugin, or in Tor, it would still be something we needed to coordinate with the servers in question. cheers, -- Nick

1 0

Mnemonic 80-bit phrases (proposal)
by Sai 21 Mar '12

21 Mar '12

Hello all. We've written up our proposal for mnemonic .onion URLs. See https://docs.google.com/document/d/sT5CulCVl0X5JeOv4W_wC_A/edit?disco=AAAAA… for details; please read the full intro for explanations and caveats, as some are important. tl;dr: It's a system that would have all three properties of being secure, distributed, and human-meaningful… but would *not* also have choice of name (though it has the required *canonicality* of names), and has a somewhat absurdist definition of 'meaningful'. :-P Please feel free to put comments there or on list. Right now we're at the stage just before implementation; namely, we haven't yet collated the necessary dictionaries, but we have a reasonably good idea of how the system would work, including needed constraints on the dictionaries. If you have suggestions or comments, now is a good time to talk about them, so that if any of it affects the dictionary collation step we don't waste work. Thanks, Sai

6 13

A modest proposal for a petname system in ideas/xxx-onion-nyms.txt
by Jacob Appelbaum 19 Mar '12

19 Mar '12

Hi, Arturo and I have discussed a possible petname system for tor2web that would make it simple to remember hidden service names; it's not perfect, it's not secure and it requires comment from the community. The basic idea is to make it easy to deploy and see if anyone cares to use it. Here's the proposal in url form: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-on… Here's the proposal as text: Filename: xxx-onion-nyms.txt Title: .onion nym system Author: Arturo FilastÃ², Jacob Appelbaum Created: 17 December 2011 Status: Draft 1. Intro and Motivation The main issue that prohibits the wide scale adoption of .onion addressing is the fact that they are not human memorable. While Zooko's triangle says that you can only have at most two of "memorable", "secure" and "global" it is possible to build a simple nym mechanism that relies on the current .onion addressing system. We define a basic registration system generally and also it's particual application to the tor2web network. This is a very simple kind of petname system for applications such as tor2web. 2. Definitions These are the definitions of the actors involved in the process. Beppe - The owner of the Tor Hidden Service User - A random user of Tor/tor2web v2cbb2l4lsnpio4q.onion - The .onion address that Beppe is interested in registering antani - The nym Beppe is interested in associating to v2cbb2l4lsnpio4q.onion t2w - A tor2web node 3. Registration This is the process through which Beppe is able to make a registration for his chosen nym. 3.1 General implementation Beppe wishes to register "antani" to point to v2cbb2l4lsnpio4q.onion so he creates a a TCP service listening on his .onion will respond with the string "reg antani" when interrogated. The requester will make a lookup in his database to see if "antani" is already registered. If it is not registered the "antani" <-> v2cbb2l4lsnpio4q.onion mapping is created. A timestamp is added to the database. 3.2 Tor2web implementation Beppe creates a file called "onion.txt" containing the string "reg antani" and uploads it to the root of his web server. When User visits v2cbb2l4lsnpio4q.tor2web.org the t2w checks if his database contains a mapping with v2cbb2l4lsnpio4q.onion, if it does not, it requests the http://v2cbb2l4lsnpio4q.onion/onion.txt file. If the file exists t2w reads it and extracts the "antani" string. A lookup is made in his database. If "antani" is not registered he creates a mapping between "antani" and v2cbb2l4lsnpio4q.onion. A timestamp is added to the database. 4. Expiration A nym will expire if either the HS goes offline for longer than a given time threshold or if he explicitly requests removal of the association to that particualr nym. This allows dynamic reallocation of nyms and avoids nym squatting. 4.1 Time delay We define the default tiem threshold to be 30 days since the last check. At the time of expiry or anytime before, another request is made to either the TCP service or for the "onion.txt" file. If the Hidden Service is offline or if the requested mapping has changed the mapping is removed or modified. If the onion.txt is unchanged, the nym remains valid and the database timestamp entry is updated. 4.2 Release The HS can specify the "release" string to delete the entry from the nym database. 5. Synchronization To keep the database of registered nyms up to date in for many t2w nodes, a synchronization mechanism is required but currently out of scope for this document. All the best, Jacob

5 5

TorHS related files re-organization ?
by Fabio Pietrosanti (naif) 18 Mar '12

18 Mar '12

While thinking about TorHS key protection, it would be also nice to think about "re-organizing" the way the TorHS describe store it's data. One of the example issue i see is that currently the hostname of a TorHS is written to a text file. This provide two major drawbacks: - Application integration Any application willing to integrate with Tor and ship Tor together with the application (GlobaLeaks, TorChat, etc) must do a file i/o operation to know the hostname. If the hostname could be known via Tor ControlPort the applications integrating Tor would have a much clean and dynamic way to know it's local TorHS hostname. - Security issue Looking at the server seizure threat scenario, who seize the computer running TorHS will be able to know the identity of the TorHS itself by looking at the "hostname" file. In the context of protection by using a password to protect the TorHS key, also the hostname information (currently in "hostname" file), would need to be protected. So in such context it would be eventually useful to think about changing the structure of the HiddenServiceDir files, by merging together the "hostname" file and the TorHS key. Even better it would be cool to have an abstracted "data storage" for such kind of information, so that it would be possible to keep it file based, sql based, remotely hosted over an web services, etc. Having something like: HiddenServiceStorage file://etc/tor/hiddenservice HiddenServiceStorage dbm://etc/tor/hiddenservice.db HiddenServiceStorage http://username@password:myremotekeyhostingservice/givemykeys?${{TorServerI… While for the protection schema it may have a file protection schema like: HiddenServiceEncryptionMethod pgp, scrypt, plain, exec://usr/bin/customscript -naif

2 4

Tor HS keys password protection against impersonation attacks?
by Fabio Pietrosanti (naif) 18 Mar '12

18 Mar '12

Hi, thinking about Tor Hidden services, they are managed by using Hidden Services client keys. The Tor HS keys are "private keys" that may require to be protected because they represent also the "identity" of the Tor HS and if stolen, it would be possible to carry on impersonation attack on connecting to Tor HS. Accepting connections on behalf of the real TorHS, with the goal to steal passwords, provide fake data to clients, exploit them, etc. The Tor HS keys are even more sensible than the X509v3, as it does provide: - identity (similar to an internet domain name) - routing (similar to an internet IP address) - encryption (they provide e2e encryption, i don't know if there are attacks on crypto if they get stolen) So owning a Tor HS key it's like owning a user domain name, acquiring it's ip address and the x509v3 private key of his digital certificate bound to his domain name. As a protection schema it would be possible to create the Tor HS private key encrypted with a passphrase, like it's possible to do for x509v3 PEM certificates. That the passphrase to unlock the Tor HS key, could be provided via Tor Control Port, so an external process (UI, scripts) could manage the setup of the passphrase. That way even in case of seizure of the server running the Tor HS it would not be possible to who seized the Tor HS Server to do actively Impersonation attacks of the Tor HS. -naif

3 4

[PATCH] tor-exit-notice.html: shorten Cornell URLs
by Christian Kujau 17 Mar '12

17 Mar '12

Hi, these ever so long law.cornell.edu URLs are now automatically redirecting to a shorter version - let's use that in our tor-exit-notice.html as well. Christian. diff --git a/contrib/tor-exit-notice.html b/contrib/tor-exit-notice.html index de3be17..8cf5c29 100644 --- a/contrib/tor-exit-notice.html +++ b/contrib/tor-exit-notice.html @@ -87,7 +87,7 @@ seize this router will accomplish nothing. Furthermore, this machine also serves as a carrier of email, which means that its contents are further protected under the ECPA. <a -href="http://www4.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00002707----000…">18 +href="http://www.law.cornell.edu/uscode/text/18/2707">18 USC 2707</a> explicitly allows for civil remedies ($1000/account plus legal fees) in the event of a seizure executed without good faith or probable cause (it @@ -105,7 +105,7 @@ used to violate the DMCA, please be aware that this machine does not host or contain any illegal content. Also be aware that network infrastructure maintainers are not liable for the type of content that passes over their equipment, in accordance with <a -href="http://www4.law.cornell.edu/uscode/html/uscode17/usc_sec_17_00000512----000…">DMCA +href="http://www.law.cornell.edu/uscode/text/17/512">DMCA "safe harbor" provisions</a>. In other words, you will have just as much luck sending a takedown notice to the Internet backbone providers. Please consult <a href="https://www.torproject.org/eff/tor-dmca-response">EFF's prepared -- BOFH excuse #151: Some one needed the powerstrip, so they pulled the switch plug.

2 1

Proposal: Message-based Inter-controller IPC Channel
by Mike Perry 17 Mar '12

17 Mar '12

Filename: xxx-postmessage-ipc.txt Title: Message-based Inter-controller IPC Channel Author: Mike Perry Created: 16-03-2012 Status: Proposed Target: 0.2.4.x Overview This proposal seeks to create a means for inter-controller communication using the Tor Control Port. Motivation With the advent of pluggable transports, bridge discovery mechanisms, and tighter browser-Vidalia integration, we're going to have an increasing number of collaborating Tor controller programs communicating with each other. Rather than define new pairwise IPC mechanisms for each case, we will instead create a generalized message-passing mechanism through the Tor Control Port. Control Protocol Specification Changes CONTROLLERNAME command Sent from the client to the server. The syntax is: "CONTROLLERNAME" SP ControllerID ControllerID = 1*(ALNUM / "_") Server returns "250 OK" and records the ControllerID to use for this control port connection for messaging information if successful, or "553 Controller name already in use" if the name is in use by another controller, or if an attempt is made to register the special names "all" or "unset". [CONTROLLERNAME need not be issued to send POSTMESSAGE commands, and CONTROLLERNAME may be unsupported by initial POSTMESSAGE implementations in Tor.] POSTMESSAGE command Sent from the client to the server. The syntax is: "POSTMESSAGE" SP "@" DestControllerID SP LineItem CRLF DestControllerID = "all" / 1*(ALNUM / "_") If DestControllerID is "all", the message will be posted to all controllers that have "SETEVENTS POSTMESSAGE" set. Otherwise, the message should be posted to the controller with the appropriate ControllerID. Server returns "250 OK" if successful, or "552 Invalid destination controller name" if the name is not registered. [Initial implementations may require DestControllerID always be "all"] POSTMESSAGE event "650" SP "POSTMESSAGE" SP MessageID SP SourceControllerID SP "@" DestControllerID SP LineItem CRLF MessageID = 1*DIGIT SourceControllerID = "unset" / 1*(ALNUM / "_") DestControllerID = "all" / 1*(ALNUM / "_") MessageID is an incrementing integer identifier that uniquely identifies this message to all controllers. The SourceControllerID is the value from the sending controller's CONTROLLERNAME command, or "unset" if the CONTROLLERNAME command was not used or unimplemented. GETINFO commands "recent-messages" -- Retrieves messages sent to ControllerIDs that match the current controller in POSTMESSAGE event format. This list should be generated on the fly, to handle disconnecting controllers. "new-messages" -- Retrieves the last 10 "unread" messages sent to this controller, in POSTMESSAGE event format. If SETEVENTS POSTMESSAGE was set, this command should always return nothing. "list-controllers" -- Retrieves a list of all connected controllers with either their registered ControllerID or "unset". Implementation plan The POSTMESSAGE protocol is designed to be incrementally deployable. Initial implementations are only expected to implement broadcast capabilities and SETEVENTS based delivery. CONTROLLERNAME need not be supported, nor do non-"@all" POSTMESSAGE destinations. To support command-based controllers (which do not use SETEVENTS) such as Torbutton, at minimum the "GETINFO recent-messages" command is needed. However, Torbutton does not have immediate need for this protocol. -- Mike Perry

2 2

Tor and DNS - draft finalized into proposal
by Ondrej Mikle 15 Mar '12

15 Mar '12

Hi all, the DNS/DNSSEC resolving draft for seems to be finished. I added a few thoughts on mitigating circuit correlation (mentioned in proposal 171). Somebody could look at those if they are not totally stupid (last two paragraphs of section 7). A note is added about the "DNSSEC stapling" [1] (extremely difficult, won't be implemented). The draft is here (full text pasted at the end of this mail): https://github.com/hiviah/torspec/blob/master/proposals/ideas/xxx-dns-dnsse… The draft could probably be given a "proposal number" and merged into torspec proposals directory unless there is an objection. I'll leave few weeks (2-3) in case someone finds a vulnerability or has an objection. After that I could slowly begin implementing it in a separate branch. [1] https://lists.torproject.org/pipermail/tor-dev/2012-February/003285.html Ondrej ---- pasted proposal (hopfully will wrap well) ---- Filename: xxx-dns-dnssec.txt Title: Support for full DNS and DNSSEC resolution in Tor Authors: Ondrej Mikle Created: 4 February 2012 Modified: 10 March 2012 Status: Draft 0. Overview Adding support for any DNS query type to Tor, as well as DNSSEC support. 0.1. Motivation Many applications running over Tor need more than just resolving FQDN to IPv4 and vice versa. Sometimes to prevent DNS leaks the applications have to be hacked around to be supplied necessary data by hand (e.g. SRV records in XMPP). TLS connections will benefit from planned TLSA record that provides certificate pinning to avoid another Diginotar-like fiasco. DNSSEC is part of the DNS protocol and the most appropriate place for DNSSEC API would be probably in OS libraries (e.g. libc). However that will probably take time until it becomes widespread. On the Tor's side (as opposed to application's side), DNSSEC will provide protection against DNS cache-poisoning attacks (provided that exit is not malicious itself, but still reduces attack surface). 1. Design 1.1 New cells There will be two new cells, RELAY_DNS_BEGIN and RELAY_DNS_RESPONSE (we'll use DNS_BEGIN and DNS_RESPONSE for short below). DNS_BEGIN payload: DNS packet data (variable length) The DNS packet must be generated internally by libunbound to avoid fingerprinting users by differences in client resolvers' behavior. DNS_RESPONSE payload: total length (2 octets) data (variable) Data contains the reply DNS packet or its part if packet would not fit into the cell. Total length describes length of complete response packet. AXFR and IXRF are not supported in this cell by design (see specialized tool below). 2. Interfaces to applications DNSPort evdns - existing implementation will be updated to use DNS_BEGIN. SOCKS proxy - new command will be added, containing RR type, class and query. Response will simply contain the DNS packet. 3. New options in configuration file libunbound takes couple of parameters, e.g. trust anchors and cache-size. In order not to put them all into torrc, there will be only one option, configuration file name. Tor will be distributed with some sensible defaults. New option will be named UnboundConfig and value will be filename. An option DNSQueryPolicy will determine what query types and classes are permitted: - common - class INTERNET, RR types listed on https://en.wikipedia.org/wiki/List_of_DNS_record_types#Resource_records - full - any query type and class is allowed Class CHAOS in "common" would not be of much use, since its prevalent use is for asking authoritative servers. For client side, full validation would be optional described by option DNSValidation (0|1). By default validation is turned on, otherwise it would be easy to fingerprint people who turned it on and asked for not-so-common records like SRV. 4. Changes to directory flags Exit nodes will signal their resolving capability by two flags: - CommonDNS - reflects "common" DNSQueryPolicy - FullDNS - reflects "full" DNSQueryPolicy Exit node asked for a RR type not in CommonDNS policy will return REFUSED in as status in the reply DNS packet contained in DNS_RESPONSE cell. If new types are added to CommonDNS set (e.g. new RFC adds a record type) and exit node's Tor version does not recognize it as allowed, it will send REFUSED as well. 5. Implementation notes There will be one instance of ub_ctx (libunbound resolver structure) in Tor, libunbound is thread-safe. Client will periodically purge incomplete DNS replies. Any unexpected DNS_RESPONSE will be dropped. Request for special names (.onion, .exit, .noconnect) will return REFUSED. RELAY_BEGIN would function "normally", there is no need for returning DNS data. In case of malicious exit, client can't check he's really connected to whatever IP is in A/AAAA. We won't send any NSEC/NSEC3 back in case FQDN does not exist, it would needlessly complicate things. Client can check by extra query on DNSPort. AD flag must be zeroed out on client unless validation is performed. 6. Separate tool for AXFR The AXFR tool will have similar interface like tor-resolve, but will return raw DNS data. Parameters are: query domain, server IP of authoritative DNS. The tool will transfer the data through "ordinary" tunnel using RELAY_BEGIN and related cells. This design decision serves two goals: - DNS_BEGIN and DNS_RESPONSE will be simpler to implement (lower chance of bugs) - in practice it's often useful do AXFR queries on secondary authoritative DNS servers IXFR will not be supported (infrequent corner case, can be done by manual tunnel creation over Tor if truly necessary). 7. Security implications Client as well as exit MUST block attempts to resolve local RFC 1918, 4193, 4291 adresses (PTR). An exit node resolving names will use libunbound for all types of resolving, including lookup of A/AAAA records when connecting stream to desired server. Ordinary streams will gain a small benefit of defense against DNS cache poisoning on exit node's network. Transaction ID is provided randomly by libunbound, no need to modify. This affects only DNSPort and SOCKS interfaces. As proposal 171 mentions, we need mitigate circuit correlation. One solution would be keeping multiple streams to multiple exit nodes and picking one at random for DNS resolution. Other would be keeping DNS-resolving circuit open only for a short time (e.g. 1-2 minutes). Yet another option for mitigating circuit correlation would be having separate circuit for each application, but that would require some cooperation of application and Tor, e.g. via some LD_PRELOAD mechanism. 8. TTL normalization idea A bit complex on implementation, because it requires parsing DNS packets at exit node. TTL in reply DNS packet MUST be normalized at exit node so that client won't learn what other clients queried. The normalization is done in following way: - for a RR, the original TTL value received from authoritative DNS server should be used when sending DNS_RESPONSE, trimming the values to interval [5, 600] - does not pose "ghost-cache-attack", since once RR is flushed from libunbound's cache, it must be fetched anew 9. Implementation notes I noticed that libunbound does not always parallelize requests that could be parallelized when using a forwarder (this does not apply to unrelated queries). Thus, A query for addons.mozilla.org looks like (note the interleaving of query/reponse): Time Info 0.000000 Standard query A addons.mozilla.org 0.178366 Standard query response A 63.245.217.112 RRSIG 0.178572 Standard query DNSKEY <Root> 0.178617 Standard query response DNSKEY DNSKEY RRSIG 0.178981 Standard query DS org 0.179041 Standard query response DS DS RRSIG 0.179192 Standard query DNSKEY org 0.179233 Standard query response DNSKEY DNSKEY DNSKEY DNSKEY RRSIG RRSIG 0.179505 Standard query DS mozilla.org 0.179562 Standard query response DS RRSIG 0.179717 Standard query DNSKEY mozilla.org 0.179762 Standard query response DNSKEY DNSKEY DNSKEY RRSIG RRSIG Further investigation is needed how to work around this. Maybe future version will have it fixed, since I see DNS queries exiting from unbound forwarder to authoritative DNS server are parallelized. 10. "DNSSEC stapling" The following idea tries to mitigate attack where observer of exit node can learn the fact that client's OR is "heating up DNS cache". Instead of asking for several records (DS, DNSKEY, etc.), exit node would send all of them at once in a "stapled response". Unfortunately this is extremely difficult to implement correctly [1] [2]. Thus we need to live with fact that exit node or an eavesdropper of such exit node will know that an OR used some TLD for the first time. Causing unrelated errors or vulnerabilities in Tor by implementing this algorithm is not worth the risk. References [1] https://www.ietf.org/mail-archive/web/dane/current/msg02823.html [2] http://unbound.net/pipermail/unbound-users/2012-February/002239.html

2 3