tor-dev March 2012

tor-dev@lists.torproject.org

35 participants
30 discussions

Proposal 188: Bridge Guards and other anti-enumeration defenses
by Nick Mathewson 12 Jun '12

12 Jun '12

Filename: 188-bridge-guards.txt Title: Bridge Guards and other anti-enumeration defenses Author: Nick Mathewson Created: 14 Oct 2011 Status: Open 1. Overview Bridges are useful against censors only so long as the adversary cannot easily enumerate their addresses. I propose a design to make it harder for an adversary who controls or observes only a few nodes to enumerate a large number of bridges. Briefly: bridges should choose guard nodes, and use the Tor protocol's "Loose source routing" feature to re-route all extend requests from clients through an additional layer of guard nodes chosen by the bridge. This way, only a bridge's guard nodes can tell that it is a bridge, and the attacker needs to run many more nodes in order to enumerate a large number of bridges. I also discuss other ways to avoid enumeration, recommending some. These ideas are due to a discussion at the 2011 Tor Developers' Meeting in Waterloo, Ontario. Practically none of the ideas here are mine; I'm just writing up what I remember. 2. History and Motivation Under the current bridge design, an attacker who runs a node can identify bridges by seeing which "clients" make a large number of connections to it, or which "clients" make connections to it in the same way clients do. This has been a known attack since early versions {XXXX check} of the design document; let's try to fix it. 2.1. Related ideas: Guard nodes The idea of guard nodes isn't new: since 0.1.1, Tor has used guard nodes (first designed as "Helper" nodes by Wright et al in {XXXX}) to make it harder for an adversary who controls a smaller number of nodes to eavesdrop on clients. The rationale was: an adversary who controls or observes only one entry and one exit will have a low probability of correlating any single circuit, but over time, if clients choose a random entry and exit for each circuit, such an adversary will eventually see some circuits from each client with a probability of 1, thereby building a statistical profile of the client's activities. Therefore, let each client choose its entry node only from among a small number of client-selected "guard" nodes: the client is still correlated with the same probability as before, but now the client has a nonzero chance of remaining unprofiled. 2.2. Related idea: Loose source routing Since the earliest versions of Onion Routing, the protocol has provided "loose source routing". In strict source routing, the source of a message chooses every hop on the message's path. But in loose source routing, the message traverses the selected nodes, but may also traverse other nodes as well. In other words, the client selects nodes N_a, N_b, and N_c, but the message may in fact traverse any sequence of nodes N_1...N_j, so long as N_1=N_a, N_x=N_b, and N_y=N_c, for 1 < x < y. Tor has retained this feature, but has not yet made use of it. 3. Design Every bridge currently chooses a set of guard nodes for its circuits. Bridges should also re-route client circuits through these circuits. Specifically, when a bridge receives a request from a client to extend a circuit, it should first create a circuit to its guard, and then relay that extend cell through the guard. The bridge should add an additional layer of encryption to outgoing cells on that circuit corresponding to the encryption that the guard will remove, and remove a layer of encryption on incoming cells on that circuit corresponding to the encryption that the guard will add. 3.1. An example This example doesn't add anything to the design above, but has some interesting inline notes. - Alice has connected to her bridge Bob, and built a circuit through Bob, with the negotiated forward and reverse keys KB_f and KB_r. - Alice then wants to extend the circuit to node Charlie. She makes a hybrid-encrypted onionskin, encrypted to Charlie's public key, containing her chosen g^x value. She puts this in an extend cell: "Extend (Charlie's address) (Charlie's OR Port) (Onionskin) (Charlie's ID)". She encrypts this with KB_f and sends it as a RELAY_EARLY cell to Bob. - Bob receives the RELAY_EARLY cell, and decrypts it with KB_f. He then sees that it's an extend cell for him. So far, this is exactly the same as the current procedure that Alice and Bob would follow. Now we diverge: - Instead of connecting to Charlie directly, Bob makes sure that he is connected to his guard, Guillaume. Bob uses a CREATE_FAST cell (or a CREATE cell, but see 4.1 below) to open a circuit to Guillaume. Now Bob and Guillaume share keys KG_f and KG_b. - Now Bob encrypts the Extend cell body with KG_f and sends it as a RELAY_EARLY cell to Guillaume. - Guillaume receives it, decrypts it with KG_f, and sees: "Extend (Charlie's address) (Charlie's OR Port) (Onionskin) (Charlie's ID)". Guillaume acts accordingly: creating a connection to Charlie if he doesn't have one, ensuring that the ID is as expected, and then sending the onionskin in a create cell on that connection. Note that Guillaume is behaving exactly as a regular node would upon receiving an Extend cell. - Now the handshake finishes. Charlie receives the onionskin and sends Guillaume "CREATED g^y,KH". Guillaume sends Bob "E(KG_r, EXTENDED g^y KH)". (Charlie and Guillaume are still running as regular Tor nodes do today). - With this extend cell, and with all future relay cells received on this circuit, Bob first decrypts the cell with KG_r, then re-encrypts it with KB_r, then passes it to Alice. When Alice receives the cell, it will be just as she would have received if Bob had extended to Charlie directly. - With all future outgoing cells that he receives from Alice, Bob first decrypts the cell with KA_f, and if the cell does not have Bob as its destination, Bob encrypts it with KG_f before passing it to Guillaume. Note that this design does not require that our stream cipher operations be transitive, even though they are. Note also that this design requires no change in behavior from any node other than Bob the bridge. Finally, observe that even though the circuit is one hop longer than it would be otherwise, no relay's count of permissible RELAY_EARLY cells falls lower than it otherwise would. This is because the extra hop that Bob adds is done with a CREATE_FAST cell, and so he does not need to send any RELAY_EARLY cells not originated by Alice. 4. Other ideas and alternative designs In addition to the design above, there are more ways to try to prevent enumeration. 4.1. Make it harder to tell clients from bridges Right now, there are multiple ways for the node after a bridge to distinguish a circuit extended through the bridge from one originating at the bridge. (This lets the node after the bridge tell that a bridge is talking to it.) One of the giveaways here is that the first hop in a circuit is created with CREATE_FAST cells, but all subsequent hops are created with CREATE cells. In the above design, it's no longer quite so simple to tell, since all of the circuits that extend through a bridge now reach its guards through CREATE_FAST cells, whether the bridge originated them or not. (If we adopt a faster circuit extension algorithm -- for example, Goldberg, Stebila, and Ustaoglu's design instantiated over curve25519 -- we could also solve this issue by eliminating CREATE_FAST/CREATED_FAST entirely, which would also help our security margin a little.) The CREATE/CREATE_FAST distinction is not the only way for a bridge's guard to tell bridges from orginary clients, however. Most importantly, a busy bridge will open far more circuits than a client would. More subtly, the timing on response from the client will be higher and more highly variable that it would be with an ordinary client. I don't think we can make bridges behave wholly indistinguishably from clients: that's why we should go with guard nodes for bridges. 4.2. Client-enforced bridge guards What if Tor didn't have loose source routing? We could have bridges tell clients what guards to use by advertising those guard in their descriptors, and then refusing to extend circuits to any other nodes. This change would require all clients to upgrade in order to be able to use the newer bridges, and would quite possibly cause a fair amount of pain along the way. Fortunately, we don't need to go down this path. So let's not! 4.3. Separate bridge-guards and client-guards In the design above, I specify that bridges should use the same guard nodes for extending client circuits as they use for their own circuits. It's not immediately clear whether this is a good idea or not. Having separate sets would seem to make the two kinds of circuits more easily distinguishable (even though we already assume they are distinguishable). Having different sets of guards would also seem like a way to keep the nodes who guard our own traffic from learning that we're a bridge... but another set of nodes will learn that anyway, so it's not clear what we'd gain. 5. Other considerations What fraction of our traffic is bridge traffic? Will this alter our circuit selection weights? Are the current guard selection/evaluation/replacement mechanisms adequate for bridge guards, or do bridges need to get more sophisticated?

7 7

Proposal 189: AUTHORIZE and AUTHORIZED cells
by George Kadianakis 12 Jun '12

12 Jun '12

Filename: 189-authorize-cell.txt Title: AUTHORIZE and AUTHORIZED cells Author: George Kadianakis Created: 04 Nov 2011 Status: Open 1. Overview Proposal 187 introduced the concept of the AUTHORIZE cell, a cell whose purpose is to make Tor bridges resistant to scanning attacks. This is achieved by having the bridge and the client share a secret out-of-band and then use AUTHORIZE cells to validate that the client indeed knows that secret before proceeding with the Tor protocol. This proposal specifies the format of the AUTHORIZE cell and also introduces the AUTHORIZED cell, a way for bridges to announce to clients that the authorization process is complete and successful. 2. Motivation AUTHORIZE cells should be able to perform a variety of authorization protocols based on a variety of shared secrets. This forces the AUTHORIZE cell to have a dynamic format based on the authorization method used. AUTHORIZED cells are used by bridges to signal the end of a successful bridge client authorization and the beginning of the actual link handshake. AUTHORIZED cells have no other use and for this reason their format is very simple. Both AUTHORIZE and AUTHORIZED cells are to be used under censorship conditions and they should look innocuous to any adversary capable of monitoring network traffic. As an attack example, an adversary could passively monitor the traffic of a bridge host, looking at the packets directly after the TLS handshake and trying to deduce from their packet size if they are AUTHORIZE and AUTHORIZED cells. For this reason, AUTHORIZE and AUTHORIZED cells are padded with a random amount of padding before sending. 3. Design 3.1. AUTHORIZE cell The AUTHORIZE cell is a variable-sized cell. The generic AUTHORIZE cell format is: AuthMethod [1 octet] MethodFields [...] PadLen [2 octets] Padding ['PadLen' octets] where: 'AuthMethod', is the authorization method to be used. 'MethodFields', is dependent on the authorization Method used. It's a meta-field hosting an arbitrary amount of fields. 'PadLen', specifies the amount of padding in octets. 'Padding', is 'PadLen' octets of random content. 3.2. AUTHORIZED cell format The AUTHORIZED cell is a variable-sized cell. The AUTHORIZED cell format is: 'AuthMethod' [1 octet] 'PadLen' [2 octets] 'Padding' ['PadLen' octets] where all fields have the same meaning as in section 3.1. 3.3. Cell parsing Implementations MUST ignore the contents of 'Padding'. Implementations MUST reject an AUTHORIZE or AUTHORIZED cell where the 'Padding' field is not 'PadLen' octets long. Implementations MUST reject an AUTHORIZE cell with an 'AuthMethod' they don't recognize. 4. Discussion 4.1. Why not let the pluggable transports do the padding, like they are supposed to do for the rest of the Tor protocol? The arguments of section "Alternative design: Just use pluggable transports" of proposal 187, apply here as well: All bridges who use client authorization will also need camouflaged AUTHORIZE/AUTHORIZED cell. 4.2. How should multiple round-trip authorization protocols be handled? Protocols that require multiple round-trips between the client and the bridge should use AUTHORIZE cells for communication. The format of the AUTHORIZE cell is flexible enough to support messages from the client to the bridge and the inverse. In the end of a successful multiple round-trip protocol, an AUTHORIZED cell must be issued from the bridge to the client. 4.3. AUTHORIZED seems useless. Why not use VPADDING instead? As noted in proposal 187, the Tor protocol uses VPADDING cells for padding; any other use of VPADDING makes the Tor protocol kludgy. In the future, and in the example case of a v3 handshake, a client can optimistically send a VERSIONS cell along with the final AUTHORIZE cell of an authorization protocol. That allows the bridge, in the case of successful authorization, to also process the VERSIONS cell and begin the v3 handshake promptly.

6 12

txtorcon, async Tor controller
by meejah 05 Jun '12

05 Jun '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erring on the side of "release early, release often" I have put my Twisted-based (asynchronous, Python) Tor control protocol implementation online: http://readthedocs.org/docs/txtorcon/en/latest/ https://github.com/meejah/txtorcon It is MIT licensed (to match Twisted). I would certainly not consider it "done", and I made it to learn more about Twisted and Python -- criticisms, comments appreciated. Currently it has the following features (see the above-linked documentation for more, and examples): . TorControlProtocol implements the control protocol . TorState tracks the state of Tor (streams, circuits, routers, address-map), listening for updates . TorConfig provides read/write configuration access , with HS abstraction (still needs some work) . IStringAttacher, a stream-to-circuit attacher interface for new streams . launch_tor can launch slave Tor processes . integrates into Twisted's endpoints with TCPHiddenServiceEndpoint The main code is about 1600 LOC, ~4000 with tests and 25% comments (according to ohcount). There is currently 98% test coverage, if one believes code-coverage is a good metric. In the short-term, be aware that I'm planning to re-organize where things are in files. If you "import txtorcon" and use the classes like "txtorcon.TorConfig" it will all still work. Thanks for your attention, mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJPczCxAAoJEMJgKAMSgGmnTrEH/RG1TLbEsqALWyh5WSm1azYU 7QHx9eup+/NKUE8C6WLPGQyprTkL/snIRZZGYDdkz5grkxcsYaWaVNNtDdUTdctN KCi2E3rbzdUYHV0aN/VdoNvJdpa8H3J2dpyx4/kFmZ2Z04+VLZOqeX6ANMdYZbYv FXv37j0dnl15h+t57+65Cf5c8BVbSW50vqXUx/eHWS73BISq3LP30OV4Ut8k3Xbg IXVf1S/EFeoXxRoGfn9i4i4txeQNyQxCOX0k+fynvIGP+lFuYciSGgGJydYBIkhE 87TMJ//c1tPq41jn5prdbWRTE4mPWA5U03w35wUGrhUWSNUb+OhM6fV4vdRwq30= =ilGQ -----END PGP SIGNATURE-----

3 6

Thandy and what's next
by Tomas Touceda 13 May '12

13 May '12

Hello everyone, Thandy, for those who haven't heard about it by now, in few words is a package system for Tor packages and the like. One of the biggest problems we have right now is keeping users' Tor up to date, so we are trying to make time to get this going. (For more detailed information about Thandy check [1], specially the doc/ and specs/ directories) A couple of months ago, nickm and erinn worked in writing the package format spec (see [2] for more details), and now I'm going to start working as fast as I can (which may be slow) in implementing this last spec and get a working Thandy. On the more technical side, the idea is to implement this in Python as a first approach. In terms of distribution, Python isn't the best choice for platforms like Windows, but right now porting Thandy to another language isn't among the top priorities. This will probably be merged with the alpha track of releases we are making, so this can have as much testing as it can before going to stable. [1] https://gitweb.torproject.org/thandy.git/tree [2] https://gitweb.torproject.org/erinn/thandy.git/blob/934300a7c4c6c0493bedaf0… Cheers, -- Tomas Touceda Gentoo Developer - Qt, Scheme, Lisp

4 4

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

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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev March 2012