tor-commits June 2012

tor-commits@lists.torproject.org

17 participants
880 discussions

[translation/vidalia] Update translations for vidalia
by translation＠torproject.org 20 Jun '12

20 Jun '12

commit 43ed738f27a4f7f6f1ddb1339cba26621e9771c6 Author: Translation commit bot <translation(a)torproject.org> Date: Wed Jun 20 12:45:08 2012 +0000 Update translations for vidalia --- sr/vidalia_sr.po | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/sr/vidalia_sr.po b/sr/vidalia_sr.po index 189b983..4b915f8 100644 --- a/sr/vidalia_sr.po +++ b/sr/vidalia_sr.po @@ -5,14 +5,15 @@ # <portalscg(a)gmail.com>, 2012. # runasand <runa.sandvik(a)gmail.com>, 2011. # <sdpuls(a)gmail.com>, 2011. +# <sosic.marko(a)gmail.com>, 2012. # Vanja <medjutim(a)yahoo.com>, 2011. msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2012-03-21 17:52+0000\n" -"PO-Revision-Date: 2012-03-22 08:51+0000\n" -"Last-Translator: portalscg <portalscg(a)gmail.com>\n" +"PO-Revision-Date: 2012-06-20 12:34+0000\n" +"Last-Translator: sholex <sosic.marko(a)gmail.com>\n" "Language-Team: translations(a)vidalia-project.net\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -3816,7 +3817,7 @@ msgid "" "Another Vidalia process is possibly already running. If there really is not another Vidalia process running, you can choose to continue anyway.\n" "\n" "Would you like to continue starting Vidalia?" -msgstr "" +msgstr "Могуће је да је други Vidalia процес већ покренут. Ако такав процес не постоји, можете изабрати да наставите даље.\n\nДа ли желите да наставите са покретањем Vidalia-e?" msgctxt "stringutil.h" msgid "%1 secs"

1 0

[torspec/master] Add proposal 202: Two improved relay encryption protocols for Tor cells
by nickm＠torproject.org 19 Jun '12

19 Jun '12

commit 8ab02c54456fa28acc8e51ef304c65ef95b53304 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Jun 19 12:14:37 2012 -0400 Add proposal 202: Two improved relay encryption protocols for Tor cells --- proposals/000-index.txt | 2 + proposals/202-improved-relay-crypto.txt | 816 +++++++++++++++++++++++++++++++ 2 files changed, 818 insertions(+), 0 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 0293b44..c4a2ef9 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -122,6 +122,7 @@ Proposals by number: 199 Integration of BridgeFinder and BridgeFinderHelper [OPEN] 200 Adding new, extensible CREATE, EXTEND, and related cells [OPEN] 201 Make bridges report statistics on daily v3 network status requests [OPEN] +202 Two improved relay encryption protocols for Tor cells [OPEN] Proposals by status: @@ -160,6 +161,7 @@ Proposals by status: 199 Integration of BridgeFinder and BridgeFinderHelper [for 0.2.4.x+] 200 Adding new, extensible CREATE, EXTEND, and related cells 201 Make bridges report statistics on daily v3 network status requests [for 0.2.4.x] + 202 Two improved relay encryption protocols for Tor cells ACCEPTED: 117 IPv6 exits [for 0.2.4.x] 140 Provide diffs between consensuses diff --git a/proposals/202-improved-relay-crypto.txt b/proposals/202-improved-relay-crypto.txt new file mode 100644 index 0000000..dafafdd --- /dev/null +++ b/proposals/202-improved-relay-crypto.txt @@ -0,0 +1,816 @@ +Filename: 202-improved-relay-crypto.txt +Title: Two improved relay encryption protocols for Tor cells +Author: Nick Mathewson +Created: 19 Jun 2012 +Status: Open + + +Overview: + + This document describes two candidate designs for a better Tor + relay encryption/decryption protocol, designed to stymie tagging + attacks and better accord with best practices in protocol design. + + My hope is that readers will examine these protocols, evaluate their + security and practicality, improve on them, and help to pick one for + implementation in Tor. + + In section 1, I describe Tor's current relay crypto protocol, its + drawbacks, how it fits in with the rest of Tor, and some + requirements/desiderata for a replacement. In sections 2 and 3, I + propose two alternative replacements for this protocol. In section + 4, I discuss their pros and cons. + +1. Background and Motivation + +1.0. A short overview of Tor's current protocols + + The core pieces of the Tor protocol are the link protocol, + the circuit extend protocol, the relay protocol, and the stream + protocol. All are documented in [TorSpec]. + + Briefly: + + - The link protocol handles all direct pairwise communication + between nodes. Everything else is transmitted over it. It + uses TLS. + + - The circuit extend protocol uses public-key crypto to set up + multi-node virtual tunnels, called "circuits", from a client + through one or more nodes. + + *** The relay protocol uses established circuits to communicate + from a client to a node on a circuit. That's the one we'll + be talking about here. *** + + - The stream protocol is tunneled over relay protocol; clients + use it to tell servers to open anonymous TCP connections, to + send data, and so forth. Servers use it to report success or + failure opening anonymous TCP connections, to send data from + TCP connections back to clients, and so forth. + + In more detail: The link protocol's job is to connect two + computers with an encrypted, authenticated stream, to + authenticate one or both of them to the other, and to provide a + channel for passing "cells" between them. The circuit extend + protocol's job is to set up circuits: persistent tunnels that + connect a Tor client to an exit node through a series of + (typically three) hops, each of which knows only the previous and + next hop, and each of which has a set of keys that they share + only with the client. Finally, the relay protocol's job is to + allow a client to communicate bidirectionally with the node(s) on + the circuit, once their shared keys have been established. + + (We'll ignore the stream protocol for the rest of this document.) + + Note on terminology: Tor nodes are sometimes called "servers", + "relays", or "routers". I'll use all these terms more or less + interchangeably. For simplicity's sake, I will call the party + who is constructing and using a circuit "the client" or "Alice", + even though nodes sometimes construct circuits too. + + Tor's internal packets are called "cells". All the cells we deal + with here are 512 bytes long. + + The nodes in a circuit are called its "hops"; most circuits are 3 + hops long. This doesn't include the client: when Alice builds a + circuit through nodes Bob_1, Bob_2, and Bob_3, the first hop is + "Bob_1" and the last hop is "Bob_3". + +1.1. The current relay protocol and its drawbacks + + [This section describes Tor's current relay protocol. It is not a + proposal; rather it is what we do now. Sections 2 and 3 have my + proposed replacements for it.] + + A "relay cell" is a cell that is generated by the client to send + to a node, or by a node to send to the client. It's called a + "relay" cell because a node that receives one may need to relay + it to the next or previous node in the circuit (or to handle the + cell itself). + + A relay cell moving towards the client is called "inbound"; a + cell moving away is called "outbound". + + When a relay cell is constructed by the client, the client adds one + layer of crypto for each node that will process the cell, and gives + the cell to the first node in the circuit. Each node in turn then + removes one layer of crypto, and either forwards the cell to the next + node in the circuit or acts on that cell itself. + + When a relay cell is constructed by a node, it encrypts it and sends + it to the preceding node in the circuit. Each node between the + originating node and the client then encrypts the cell and passes it + back to the preceding node. When the client receives the cell, it + removes layers of crypto until it has an unencrypted cell, which it + then acts on. + + In the current protocol, the body of each relay cell contains, in + its unencrypted form: + + Relay command [1 byte] + Zeros [2 bytes] + StreamID [2 bytes] + Digest [4 bytes] + Length [2 bytes] + Data [498 bytes] + + (This only adds up to 509 bytes. That's because the Tor link + protocol transfers 512-byte cells, and has a 3 byte overhead per + cell. Not how we would do it if we were starting over at this + point.) + + At every node of a circuit, the node relaying a cell + encrypts/decrypts it with AES128-CTR. If the cell is outbound + and the "zeros" field is set to all-zeros, the node additionally + checks whether 'digest' is correct. A correct digest is the + first 4 bytes of the running SHA1 digest of: a shared secret, + concatenated with all the relay cells destined for this node on + this circuit so far, including this cell. If _that's_ true, then + the node accepts this cell. (See section 6 of [TorSpec] for full + detail; see section A.1 for a more rigorous description.) + + The current approach has some actual problems. Notably: + + * It permits tagging attacks. Because AES_CTR is an XOR-based + stream cipher, an adversary who controls the first node in a + circuit can XOR anything he likes into the relay cell, and + then see whether he/she encounters an correspondingly + defaced cell at some exit that he also controls. + + That is, the attacker picks some pattern P, and when he + would transmit some outbound relay cell C at hop 1, he + instead transmits C xor P. If an honest exit receives the + cell, the digest will probably be wrong, and the honest exit + will reject it. But if the attacker controls the exit, he + will notice that he has received a cell C' where the digest + doesn't match, but where C' xor P _does_ have a good digest. + The attacker will then know that his two nodes are on the + same circuit, and thereby be able to link the user (whom the + first node sees) to her activities (which the last node sees). + + Back when we did the Tor design, this didn't seem like a + big deal, since an adversary who controls both the first and + last node in a circuit is presumed to win already based on + traffic correlation attacks. This attack seemed strictly + worse than that, since it was trivially detectable in the + case where the attacker _didn't_ control both ends. See + section 4.4 of the Tor paper [TorDesign] for our early + thoughts here; see Xinwen Fu et al's 2009 work for a more + full explanation of the in-circuit tagging attack [XF]; and + see "The 23 Raccoons'" March 2012 "Analysis of the Relative + Severity of Tagging Attacks" mail on tor-dev (and the + ensuing thread) for a discussion of why we may want to care + after all, due to attacks that use tagging to amplify route + capture. [23R] + + It also has some less practical issues. + + * The digest portion is too short. Yes, if you're an attacker + trying to (say) change an "ls *" into an "rm *", you can + only expect to get one altered cell out of 2^32 accepted -- + and all future cells on the circuit will be rejected with + similar probability due to the change in the running hash + -- but 1/2^32 is a pretty high success rate for crypto attacks. + + * It does MAC-then-encrypt. That makes smart people cringe. + + * Its approach to MAC is H(Key | Msg), which is vulnerable to + length extension attack if you've got a Merkle-Damgard hash + (which we do). This isn't relevant in practice right now, + since the only parties who see the digest are the two + parties that rely on it (because of the MAC-then-encrypt). + + +1.2. Some feature requirements + + Relay cells can originate at the client or at a relay. Relay cells + that originate at the client are given to the first node in the + circuit, and constructed so that they will be decrypted and forwarded + by the first M-1 nodes in the circuit, and finally decrypted and + processed by the Mth node, where the client chooses M. (Usually, the + Mth node is the the last one, which will be an exit node.) Relay + cells that originate at a hop in the circuit are given to the + preceding node, and eventually delivered to the client. + + Tor provides a so called "leaky pipe" circuit topology + [TorDesign]: a client can send a cell to any node in the circuit, + not just the last node. I'll try to keep that property, although + historically we haven't really made use of it. + + In order to implement telescoping circuit construction (where the + circuit is built by iteratively asking the last node in the + circuit to extend the circuit one hop more), it's vital that the + last hop of the circuit be able to change. + + Proposal 188 [Prop188] suggests that we implement a "bridge guards" + feature: making some (non-public) nodes insert an extra hop into + the circuit after themselves, in a way that will make it harder + for other nodes in the network to enumerate them. We + therefore want our circuits to be one-hop re-extensible: when the + client extends a circuit from Bob1 to Bob2, we want Bob1 to be + able to introduce a new node "Bob1.5" into the circuit such that + the circuit runs Alice->Bob1->Bob1.5->Bob2. (This feature has + been called "loose source routing".) + + Any new approach should be able to coexist on a circuit + with the old approach. That is, if Alice wants to build a + circuit through Bob1, Bob2, and Bob3, and only Bob2 supports a + revised relay protocol, then Alice should be able to build a + circuit such that she can have Bob1 and Bob3 process each cell + with the current protocol, and Bob2 process it with a revised + protocol. (Why? Because if all nodes in a circuit needed to use + the same relay protocol, then each node could learn information + about the other nodes in the circuit from which relay protocol + was chosen. For example, if Bob1 supports the new protocol, and + sees that the old relay protocol is in use, and knows that Bob2 + supports the new one, then Bob1 has learned that Bob3 is some + node that does not support the new relay protocol.) + + Cell length needs to be constant as cells move through the + network. For historical reasons mentioned above in section 1.1, + the length of the encrypted part of a relay cell needs to be 509 + bytes. + +1.3. Some security requirements + + Two adjacent nodes on a circuit can trivially tell that they are + on the same circuit, and the first node can trivially tell who + the client is. Other than that, we'd like any attacker who + controls a node on the circuit not to have a good way to learn + any other nodes, even if he/she controls those nodes. [*] + + Relay cells should not be malleable: no relay should be able to + alter a cell between an honest sender and an honest recipient in + a way that they cannot detect. + + Relay cells should be secret: nobody but the sender and recipient + of a relay cell should be able to learn what it says. + + Circuits should resist transparent, recoverable tagging attacks: + if an attacker controls one node in a circuit and alters a relay + cell there, no non-adjacent point in the circuit should be able + to recover the relay cell as it would have received it had the + attacker not altered it. + + The above properties should apply to sequences of cells too: + an attacker shouldn't be able to change what sequence of cells + arrives at a destination (for example, by removing, replaying, or + reordering one or more cells) without being detected. + + (Feel free to substitute whatever formalization of the above + requirements makes you happiest, and add whatever caveats are + necessary to make you comfortable. I probably missed at least + two critical properties.) + + [*] Of course, an attacker who controls two points on a circuit + can probably confirm this through traffic correlation. But + we'd prefer that the cryptography not create other, easier + ways for them to do this. + +1.4. A note on algorithms + + This document is deliberately agnostic concerning the choice of + cryptographic primitives -- not because I have no opinions about + good ciphers, MACs, and modes of operation -- but because + experience has taught me that mentioning any particular + cryptographic primitive will prevent discussion of anything else. + + Please DO NOT suggest algorithms to use in implementing these + protocols yet. It will distract! There will be time later! + + If somebody _else_ suggests algorithms to use, for goodness' sake + DON'T ARGUE WITH THEM! There will be time later! + + +2. Design 1: Large-block encryption + + In this approach, we use a tweakable large-block cipher for + encryption and decryption, and a tweak-chaining function TC. + +2.1. Chained large-block what now? + + We assume the existence of a primitive that provides the desired + properties of a tweakable[Tweak] block cipher, taking blocks of any + desired size. (In our case, the block size is 509 bytes[*].) + + It also takes a Key, and a per-block "tweak" parameter that plays + the same role that an IV plays in CBC, or that the counter plays + in counter mode. + + The Tweak-chaining function TC takes as input a previous tweak, a + tweak chaining key, and a cell; it outputs a new tweak. Its + purpose is to make future cells undecryptable unless you have + received all previous cells. It could probably be something like + a MAC of the old tweak and the cell using the tweak chaining key + as the MAC key. + + (If the initial tweak is secret, I am not sure that TC needs to + be keyed.) + + [*] Some large-block cipher constructions use blocks whose size is + the multiple of some underlying cipher's block size. If we wind + up having to use one of those, we can use 496-byte blocks instead + at the cost of 2.5% wasted space. + +2.2. The protocol + +2.2.1. Setup phase + + The circuit construction algorithm needs to produce forward and + backward keys Kf and Kb, the forward and backward tweak chaining + keys TCKf and TCKb, as well as initial tweak values Tf and Tb. + +2.2.2. The cell format + + We replace the "Digest" and "Zeros" fields of the cell with a + single Z-byte "Zeros" field to determine when the cell is + recognized and correctly decrypted; its length is a security + parameter. + +2.2.3. The decryption operations + + For a relay to handle an inbound RELAY cell, it sets Tb_next to + TC(TCKb, Tb, Cell). Then it encrypts the cell using the large + block cipher keyed with Kb and tweaked with Tb. Then it sets Tb + to Tb_next. + + For a relay to handle an outbound RELAY cell, it sets Tf_next to + TC(TCKf, Tf, Cell). Then it decrypts the cell using the large + block cipher keyed with Kf and tweaked with Tf. Then it sets Tf + to Tf_next. Then it checks the 'Zeros' field on the cell; + if that field is all [00] bytes, the cell is for us. + +2.3. Security discussion + + This approach is fairly simple (at least, no more complex than + its primitives) and achieves some of our security goals. Because + of the large block cipher approach, any change to a cell will + render that cell undecryptable, and indistinguishable from random + junk. Because of the tweak chaining approach, if even one cell + is missed or corrupted or reordered, future cells will also + decrypt into random junk. + + The tagging attack in this case is turned into a circuit-junking + attack: an adversary who tries to mount it can probably confirm + that he was indeed first and last node on a target circuit + (assuming that circuits which turn to junk in this way are rare), + but cannot recover the circuit after that point. + + As a neat side observation, note that this approach improves upon + Tor's current forward secrecy, by providing forward secrecy while + circuits are still operational, since each change to the tweak + should make previous cells undecryptable if the old tweak value + isn't recoverable. + + The length of Zeros is a parameter for what fraction of "random + junk" cells will potentially be accepted by a router or client. + If Zeros is Z bytes long, then junk cells will be accepted with + P < 2^-(8*Z + 7). (The '+7' is there because the top 7 bits of + the Length field must also be 0.) + + There's no trouble using this protocol in a mixed circuit, where + some nodes speak the old protocol and some speak the + large-block-encryption protocol. + +3. Design 2: short-MAC-and-pad + + In this design, we behave more similarly to a mix-net design + (such as Mixmaster or Mixminion's headers). Each node checks a + MAC, and then re-pads the cell to its chosen length before + decoding the cell. + + This design uses as a primitive a MAC and a stream cipher. It + might also be possible to use an authenticating cipher mode, + if we can find one that works like a stream cipher and allows us + to efficiently output authenticators for the stream so far. + + NOTE TO AE/AEAD FANS: The encrypt-and-MAC model here could be + replaced with an authenticated encryption mode without too much + loss of generality. + +3.1. The protocol + +3.1.1 Setup phase + + The circuit construction algorithm needs to produce forward and + backward keys Kf and Kb, forward and backward stream cipher IVs + IVf and IVb, and forward and backward MAC keys Mf and Mb. + + Additionally, the circuit construction algorithm needs a way for + the client to securely (and secretly? XXX) tell each hop in the + circuit a value 'bf' for the number of bytes of MAC it should + expect on outbound cells and 'bb' for the number of bytes it + should use on cells it's generating. Each node can get a + different 'bf' and 'bb'. These values can be 0: if a node's bf + is 0, it doesn't authenticate cells; if its bb is 0, it doesn't + originate them. + + The circuit construction algorithm also needs a way to tell each + the client to securely (and secretly? XXX) tell each hop in the + circuit whether it is allowed to be the final destination for + relay cells. + + Set the stream Sf and the stream Sb to empty values. + +3.1.2. The cell format + + The Zeros and Digest field of the cell format are removed. + +3.1.3. The relay operations + + Upon receiving an outbound cell, a node removes the first b bytes + of the cell, and puts them aside as 'M'. The node then computes + between 0 and 2 MACs of the stream consisting of all previously + MAC'd data, plus the remainder of the cell: + + If b>0 and there is a next hop, the node computes M_relay. + + If this node was told to deliver traffic, or it is the last + node in the circuit so far, the node computes M_receive. + + M_relay is computed as MAC(stream | "relay"); M_receive is + computed as MAC(stream | "receive"). + + If M = M_receive, this cell is for the node; it should process + it. + + If M = M_relay, or if b == 0, this cell should be relayed. + + If a MAC was computed and neither of the above cases was met, + then the cell is bogus; the node should discard it and destroy + the circuit. + + The node then removes the first bf bytes of the cell, and pads the + cell at the end with bf zero bytes. Finally, the node decrypts + the whole remaining padded cell with the stream cipher. + + To handle an inbound cell, the node simply does a stream cipher + with no checking. + +3.1.4. Generating inbound cells. + + To generate an inbound cell, a node makes a 509-bb byte RELAY + cell C, encrypts that cell with Kb, appends the encrypted cell to + Sb, and prepends M_receive(Sb) to the cell. + +3.1.5. Generating outbound cells + + Generating an outbound cell is harder, since we need to know what + padding the earlier nodes will generate in order to know what + padding the later nodes will receive and compute their MACs, but + we also need to know what MACs we'll send to the later nodes in + order to compute which MACs we'll send to the earlier ones. + + Mixnet clients have needed to do this for ages, though, so the + algorithms are pretty well settled. I'll give one below in A.3. + +3.2. Security discussion + + This approach is also simple and (given good parameter choices) + can achieve our goals. The trickiest part is the algorithm that + clients must follow to package cells, but that's no so bad. + + It's not necessary to check MACs on inbound traffic, because + nobody but the client can tell scrambled messages from good ones, + and the client can be trusted to keep the client's own secrets. + + With this protocol, if the attacker tries to do a tagging attack, + the circuit should get destroyed by the next node in the circuit + that has a nonzero "bf" value, with probability == 1-2^-(8*bf). + (If there are further intervening honest nodes, they also have a + chance to detect the attack.) + + Similarly, any attempt to replay, or reorder outbound cells + should fail similarly. + + The "bf" values could reveal to each node its position in the + circuit and the client preferences, depending on how we set them; + on the other hand, having a fixed bf value would reveal to the + last node the length of the circuit. Neither option seems great. + + This protocol doesn't provide any additional forward secrecy + beyond what Tor has today. We could fix that by changing our use + of the stream cipher so that instead of running in counter mode + between cells, we use a tweaked stream cipher and change the + tweak with each cell (possibly based on the unused portion of the + MAC). + + This protocol does support loose source routing, so long as the + no padding bytes are added by any router-added nodes. + + In a circuit, every node has at least one relay cell sent to it: + even non-exit nodes get a RELAY_EXTEND cell. + +4. Discussion + + I'm not currently seeing a reason to strongly prefer one of these + approaches over another. + + In favor of large-block encryption: + - The space overhead seems smaller: we need to use up fewer + bytes in order to get equivalent looking security. + + (For example, if we want to have P < 2^64 that a cell altered + by hop 1 could be accepted by hop 2 or hop 3, *and* we want P + < 2^64 that a cell altered by hop 2 could be accepted by hop + 3, the large-block approach needs about 8 bytes for the Zeros + field, whereas the short-MAC-and-pad approach needs 16 bytes + worth of MACs.) + + - We get forward secrecy pretty easily. + + - The format doesn't leak anything about the length of the + circuit, or limit it. + + - We don't need complicated logic to set the 'b' parameters. + + - It doesn't need tricky padding code. + + In the favor of short-MAC-and-pad: + - All of the primitives used are much better analyzed and + understood. There's nothing esoteric there. The format + itself is similar to older, well-analyzed formats. + + - Most of the constructions for the large-block-cipher approach + seem less efficient in CPU cycles than a good stream cipher + and a MAC. (But I don't want to discuss that now; see section + 1.4 above!) + + Unclear: + + - Suppose that an attacker controls the first and last hop of a + circuit, and tries an end-to-end tagging attack. With + large-block encryption, the tagged cell and all future cells + on the circuit turn to junk after the tagging attack, with + P~~100%. With short-MAC-and-pad, the circuit is destroyed at + the second hop, with P ~~ 1- 2^(-8*bf). Is one of these + approaches materially worse for the attacker? + + - Can we do better than the "compute two MACs" approach for + distinguishing the relay and receive cases of the + short-MAC-and-pad protocol? + + - To what extent can we improve these protocols? + + - If we do short-MAC-and-pad, should we apply the forward + security hack alluded to in section 3.2? + +5. Acknowledgments + + Thanks to the many reviewers of the initial drafts of this + proposal. If you can make any sense of what I'm saying, they + deserve much of the credit. + +A. Formal description + + Note that in all these cases, more efficient descriptions exist. + +A.1. The current Tor relay protocol. + + Relay cell format: + + Relay command [1 byte] + Zeros [2 bytes] + StreamID [2 bytes] + Digest [4 bytes] + Length [2 bytes] + Data [498 bytes] + + Circuit setup: + + (Specified elsewhere; the client negotiates with each router in + a circuit the secret AES keys Kf, Kb, and the secret 'digest + keys' Df, and Db. They initialize AES counters Cf and Cb to + 0. They initialize the digest stream Sf to Df, and Sb to Db.) + + HELPER FUNCTION: CHECK(Cell [in], Stream [in,out]): + + 1. If the Zeros field of Cell is not [00 00], return False. + 2. Let Cell' = Cell with its Digest field set to [00 00 00 00]. + 3. Let S' = Stream | Cell'. + 4. If SHA1(S') = the Digest field of Cell, set Stream to S', + and return True. + 5. Otherwise return False. + + HELPER FUNCTION: CONSTRUCT(Cell' [in], Stream [in,out]) + + 1. Set the Zeros and Digest field of Cell' to [00] bytes. + 2. Set Stream to Stream | Cell'. + 3. Construct Cell from Cell' by setting the Digest field to + SHA1(Stream), and taking all other fields as-is. + 4. Return Cell. + + HELPER_FUNCTION: ENCRYPT(Cell [in,out], Key [in], Ctr [in,out]) + 1. Encrypt Cell's contents using AES128_CTR, with key 'Key' and + counter 'Ctr'. Increment 'Ctr' by the length of the cell. + + HELPER_FUNCTION: DECRYPT(Cell [in,out], Key [in], Ctr [in,out]) + 1. Same as ENCRYPT. + + + Router operation, upon receiving an inbound cell -- that is, one + sent towards the client. + + 1. ENCRYPT(cell, Kb, Cb) + 2. Send the decrypted contents towards the client. + + Router operation, upon receiving an outbound cell -- that is, one + sent away from the client. + + 1. DECRYPT(cell, Kf, Cf) + 2. If CHECK(Cell, Sf) is true, this cell is for us. Do not + relay the cell. + 3. Otherwise, this cell is not for us. Send the decrypted cell + to the next hop on the circuit, or discard it if there is no + next hop. + + Router operation, to create a relay cell that will be delivered + to the client. + + 1. Construct a Relay cell Cell' with the relay command, length, + stream ID, and body fields set as appropriate. + 2. Let Cell = CONSTRUCT(Cell', Sb). + 3. ENCRYPT(Cell, Kb, Cb) + 4. Send the encrypted cell towards the client. + + Client operation, receiving an inbound cell. + + For each hop H in a circuit, starting with the first hop and + ending (possibly) with the last: + + 1. DECRYPT(Cell, Kb_H, Cb_H) + + 2. If CHECK(Cell, Sb_H) is true, this cell was sent from hop + H. Exit the loop, and return the cell in its current + form. + + If we reach the end of the loop without finding the right hop, + the cell is bogus or corrupted. + + Client operation, sending an outbound cell to hop H. + + 1. Construct a Relay cell Cell' with the relay command, length, + stream ID, and body fields set as appropriate. + 2. Let Cell = CONSTRUCT(Cell', Sf_H) + 3. For i = H..1: + A. ENCRYPT(Cell, Sf_i, Cf_i) + 4. Deliver Cell to the first hop in the circuit. + +A.2. The large-block-cipher protocol + + Same as A.1, except for the following changes. + + The cell format is now: + Zeros [Z bytes] + Length [2 bytes] + StreamID [2 bytes] + Relay command [1 byte] + Data [504-Z bytes] + + Ctr is no longer a counter, but a Tweak value. + + Each key is now a tuple of (Key_Crypt, Key_TC) + + Streams are no longer used. + + HELPER FUNCTION: CHECK(Cell [in], Stream [in,out]) + 1. If the Zeros field of Cell contains only [00] bytes, + return True. + 2. Otherwise return false. + + HELPER FUNCTION: CONSTRUCT(Cell' [in], Stream [in,out]) + 1. Let Cell be Cell', with its "Zeros" field set to Z [00] + bytes. + 2. Return Cell'. + + HELPER FUNCTION: ENCRYPT(Cell [in,out], Key [in], Tweak [in,out]) + 2. Encrypt Cell using Key and Tweak + 1. Let Tweak' = TC(Key_TC, Tweak, Cell) + 3. Set Tweak to Tweak'. + + HELPER FUNCTION: DECRYPT(Cell [in,out], Key [in], Tweak [in,out]) + 1. Let Tweak' = TC(Key_TC, Tweak, Cell) + 2. Decrypt Cell using Key and Tweak + 3. Set Tweak to Tweak'. + +A.3. The short-MAC-and-pad protocol. + + Define M_relay(K,S) as MAC(K, S|"relay"). + Define M_receive(K,S) as MAC(K, S|"receive"). + Define Z(n) as a series of n [00] bytes. + Define BODY_LEN as 509 + + The cell message format is now: + + Relay command [1 byte] + StreamID [2 bytes] + Length [2 bytes] + Data [variable bytes] + + Helper function: CHECK(Cell [in], b [in], K [in], S [in,out]): + Let M = Cell[0:b] + Let Rest = Cell[b:...] + If b == 0: + Return (nil, Rest) + Let S' = S | Rest + If M == M_relay(K,S')[0:b]: + Set S = S' + Return ("relay", Rest) + If M == M_receive(K,S')[0:b]: + Set S = S' + Return ("receive", Rest) + Return ("BAD", nil) + + HELPER_FUNCTION: ENCRYPT(Cell [in,out], Key [in], Ctr [in,out]) + 1. Encrypt Cell's contents using AES128_CTR, with key 'Key' and + counter 'Ctr'. Increment 'Ctr' by the length of the cell. + + HELPER_FUNCTION: DECRYPT(Cell [in,out], Key [in], Ctr [in,out]) + 1. Same as ENCRYPT. + + Router operation, upon receiving an inbound cell: + 1. ENCRYPT(cell, Kb, Cb) + 2. Send the decrypted contents towards the client. + + Router operation, upon receiving an outbound cell: + 1. Let Status, Msg = CHECK(Cell, bf, Mf, Sf) + 2. If Status == "BAD", drop the cell and destroy the circuit. + 3. Let Cell' = Msg | Z(BODY_LEN - len(Msg)) + 4. DECRYPT(Cell', Kf, Cf) [*] + 5. If Status == "receive" or (Status == nil and there is no + next hop), Cell' is for us: process it. + 6. Otherwise, send Cell' to the next node. + + Router operation, sending a cell towards the client: + 1. Let Body = a relay cell body of BODY_LEN-bb_i bytes. + 2. Let Cell' = ENCRYPT(Body, Kb, Cb) + 3. Let Sb = Sb | Cell' + 4. Let M = M_receive(Mb, Sb)[0:b] + 5. Send the cell M | Cell' back towards the client. + + Client operation, upon receiving an inbound cell: + + For each hop H in the circuit, from first to last: + + 1. Let Status, Msg = CHECK(Cell, bb_i, Mb_i, Sb_i) + 2. If Status = "relay", drop the cell and destroy + the circuit. (BAD is okay; it means that this hop didn't + originate the cell.) + 3. DECRYPT(Msg, Kb_i, Cb_i) + 4. If Status = "receive", this cell is from hop i; process + it. + 5. Otherwise, set Cell = Msg. + + Client operation, sending an outbound cell: + + Let BF = the total of all bf_i values. + + 1. Construct a relay cell body Msg of BODY_LEN-BF bytes. + 2. For each hop i, let Stream_i = ENCRYPT(Kf_i,Z(CELL_LEN),Cf_i) + 3. Let Pad_0 = "". + 4. For i in range 1..N, where N is the number of hops: + Let Pad_i = Pad_{i-1} | Z(bf_i) + Let S_last = the last len(Pad_i) bytes of Stream_i. + Let Pad_i = Pad_i xor S_last + Now Pad_i is the padding as it will stand after node i + has processed it. + + 5. For i in range N..1, where N is the number of hops: + If this is the last hop, let M_* = M_receive. Else let + M_* = M_relay. + + Let Body = Msg xor the first len(Msg) bytes of Stream_i + + Let M = M_*(Mf, Body | Pad_(i-1)) + + Set Msg = M[:bf_i] | Body + + 6. Send Msg outbound to the first relay in the circuit. + + + [*] Strictly speaking, we could omit the pad-and-decrypt + operation once we know we're the final hop. + + + +R. References + +[Prop188] Tor Proposal 188: Bridge Guards and other anti-enumeration defenses + https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/188-bridge-g… + +[TorSpec] The Tor Protocol Specification + https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.t… + +[TorDesign] Dingledine et al, "Tor: The Second Generation Onion + Router", + https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf + +[Tweak] Liskov et al, "Tweakable Block Ciphers", + http://www.cs.berkeley.edu/~daw/papers/tweak-crypto02.pdf + +[XF] Xinwen Fu et al, "One Cell is Enough to Break Tor's Anonymity" + +[23R] The 23 Raccoons, "Analysis of the Relative Severity of Tagging + Attacks" http://archives.seul.org/or/dev/Mar-2012/msg00019.html + (You'll want to read the rest of the thread too.)

1 0

[stem/master] TestCase's skipTest method unavailable before python 2.7
by atagar＠torproject.org 19 Jun '12

19 Jun '12

commit ed0db8f0defa6d94e62b20c7a2cc335f3801d91a Author: Damian Johnson <atagar(a)torproject.org> Date: Mon Jun 18 09:52:51 2012 -0700 TestCase's skipTest method unavailable before python 2.7 Blarg! The unit testing's skipTest method was a new addition in python 2.7. This is especially pesky since skipTest alters the control flow of the tests (raising an exception so we can place it in setUp methods). Options are to either monkey patch support into our testing module (ick!) or add a fallback everywhere we use skipTest. This change adds a best-effort skip method to the runner, then leaves it to the caller to return out of the method (reporting success for skipped tests). Sucks, but best that we can do until we drop *both* python 2.5 and 2.6 compatability, which probably won't happen until we finally move to the 3.x series. --- test/integ/connection/authentication.py | 23 ++++++- test/integ/connection/connect.py | 6 +- test/integ/control/base_controller.py | 17 ++++- test/integ/control/controller.py | 15 +++- test/integ/descriptor/extrainfo_descriptor.py | 5 +- test/integ/descriptor/server_descriptor.py | 5 +- test/integ/process.py | 4 +- test/integ/response/protocolinfo.py | 9 ++- test/integ/socket/control_message.py | 19 ++++- test/integ/socket/control_socket.py | 15 +++- test/integ/util/system.py | 100 +++++++++++++++++-------- test/integ/version.py | 8 +- test/runner.py | 30 +++++++- test/unit/descriptor/server_descriptor.py | 7 +- 14 files changed, 199 insertions(+), 64 deletions(-) diff --git a/test/integ/connection/authentication.py b/test/integ/connection/authentication.py index 31407a3..8c5c06d 100644 --- a/test/integ/connection/authentication.py +++ b/test/integ/connection/authentication.py @@ -95,7 +95,6 @@ def _get_auth_failure_message(auth_type): class TestAuthenticate(unittest.TestCase): def setUp(self): - test.runner.require_control(self) self.cookie_auth_methods = [AuthMethod.COOKIE] tor_version = test.runner.get_runner().get_tor_version() @@ -107,6 +106,8 @@ class TestAuthenticate(unittest.TestCase): Tests that the authenticate function can authenticate to our socket. """ + if test.runner.require_control(self): return + runner = test.runner.get_runner() with runner.get_tor_socket(False) as control_socket: stem.connection.authenticate(control_socket, test.runner.CONTROL_PASSWORD, runner.get_chroot()) @@ -117,6 +118,8 @@ class TestAuthenticate(unittest.TestCase): Tests that the authenticate function can authenticate via a Controller. """ + if test.runner.require_control(self): return + runner = test.runner.get_runner() with runner.get_tor_controller(False) as controller: stem.connection.authenticate(controller, test.runner.CONTROL_PASSWORD, runner.get_chroot()) @@ -127,6 +130,8 @@ class TestAuthenticate(unittest.TestCase): Tests the authenticate function with something like its pydoc example. """ + if test.runner.require_control(self): return + runner = test.runner.get_runner() tor_options = runner.get_options() @@ -162,6 +167,8 @@ class TestAuthenticate(unittest.TestCase): Tests the authenticate function's password argument. """ + if test.runner.require_control(self): return + # this is a much better test if we're just using password auth, since # authenticate will work reguardless if there's something else to # authenticate with @@ -198,6 +205,8 @@ class TestAuthenticate(unittest.TestCase): individually. """ + if test.runner.require_control(self): return + runner = test.runner.get_runner() tor_options = runner.get_options() is_cookie_only = test.runner.Torrc.COOKIE in tor_options and not test.runner.Torrc.PASSWORD in tor_options @@ -220,6 +229,8 @@ class TestAuthenticate(unittest.TestCase): Tests the authenticate_none function. """ + if test.runner.require_control(self): return + auth_type = stem.connection.AuthMethod.NONE if _can_authenticate(auth_type): @@ -232,6 +243,8 @@ class TestAuthenticate(unittest.TestCase): Tests the authenticate_password function. """ + if test.runner.require_control(self): return + auth_type = stem.connection.AuthMethod.PASSWORD auth_value = test.runner.CONTROL_PASSWORD @@ -259,6 +272,8 @@ class TestAuthenticate(unittest.TestCase): Tests the authenticate_cookie function. """ + if test.runner.require_control(self): return + auth_value = test.runner.get_runner().get_auth_cookie_path() for auth_type in self.cookie_auth_methods: @@ -281,6 +296,8 @@ class TestAuthenticate(unittest.TestCase): value. """ + if test.runner.require_control(self): return + auth_value = test.runner.get_runner().get_test_dir("fake_cookie") # we need to create a 32 byte cookie file to load from @@ -317,6 +334,8 @@ class TestAuthenticate(unittest.TestCase): shouldn't exist. """ + if test.runner.require_control(self): return + for auth_type in self.cookie_auth_methods: auth_value = "/if/this/exists/then/they're/asking/for/a/failure" self.assertRaises(stem.connection.UnreadableCookieFile, self._check_auth, auth_type, auth_value, False) @@ -328,6 +347,8 @@ class TestAuthenticate(unittest.TestCase): socket. """ + if test.runner.require_control(self): return + auth_value = test.runner.get_runner().get_torrc_path(True) for auth_type in self.cookie_auth_methods: diff --git a/test/integ/connection/connect.py b/test/integ/connection/connect.py index 3af249b..b3ba210 100644 --- a/test/integ/connection/connect.py +++ b/test/integ/connection/connect.py @@ -11,8 +11,6 @@ import test.runner class TestConnect(unittest.TestCase): def setUp(self): - test.runner.require_control(self) - # prevents the function from printing to the real stdout self.original_stdout = sys.stdout sys.stdout = StringIO.StringIO() @@ -25,6 +23,8 @@ class TestConnect(unittest.TestCase): Basic sanity checks for the connect_port function. """ + if test.runner.require_control(self): return + runner = test.runner.get_runner() control_socket = stem.connection.connect_port( @@ -44,6 +44,8 @@ class TestConnect(unittest.TestCase): Basic sanity checks for the connect_socket_file function. """ + if test.runner.require_control(self): return + runner = test.runner.get_runner() control_socket = stem.connection.connect_socket_file( diff --git a/test/integ/control/base_controller.py b/test/integ/control/base_controller.py index ab5ded5..d74c160 100644 --- a/test/integ/control/base_controller.py +++ b/test/integ/control/base_controller.py @@ -34,15 +34,14 @@ class StateObserver: self.timestamp = timestamp class TestBaseController(unittest.TestCase): - def setUp(self): - test.runner.require_control(self) - def test_connect_repeatedly(self): """ Connects and closes the socket repeatedly. This is a simple attempt to trigger concurrency issues. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket() as control_socket: controller = stem.control.BaseController(control_socket) @@ -55,6 +54,8 @@ class TestBaseController(unittest.TestCase): Tests a basic query with the msg() method. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket() as control_socket: controller = stem.control.BaseController(control_socket) test.runner.exercise_controller(self, controller) @@ -64,6 +65,8 @@ class TestBaseController(unittest.TestCase): Tests the msg() method against an invalid controller command. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket() as control_socket: controller = stem.control.BaseController(control_socket) response = controller.msg("invalid") @@ -74,6 +77,8 @@ class TestBaseController(unittest.TestCase): Tests the msg() method against a non-existant GETINFO option. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket() as control_socket: controller = stem.control.BaseController(control_socket) response = controller.msg("GETINFO blarg") @@ -85,6 +90,8 @@ class TestBaseController(unittest.TestCase): is a simple attempt to trigger concurrency issues. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket() as control_socket: controller = stem.control.BaseController(control_socket) @@ -119,6 +126,8 @@ class TestBaseController(unittest.TestCase): listeners will still receive all of the enqueued events. """ + if test.runner.require_control(self): return + class ControlledListener(stem.control.BaseController): """ Controller that blocks event handling until told to do so. @@ -173,6 +182,8 @@ class TestBaseController(unittest.TestCase): remove_status_listener() methods. """ + if test.runner.require_control(self): return + state_observer = StateObserver() with test.runner.get_runner().get_tor_socket(False) as control_socket: diff --git a/test/integ/control/controller.py b/test/integ/control/controller.py index 55a86ec..5c10b3d 100644 --- a/test/integ/control/controller.py +++ b/test/integ/control/controller.py @@ -13,14 +13,13 @@ import stem.response.protocolinfo import test.runner class TestController(unittest.TestCase): - def setUp(self): - test.runner.require_control(self) - def test_from_port(self): """ Basic sanity check for the from_port constructor. """ + if test.runner.require_control(self): return + if test.runner.Torrc.PORT in test.runner.get_runner().get_options(): with stem.control.Controller.from_port(control_port = test.runner.CONTROL_PORT) as controller: self.assertTrue(isinstance(controller, stem.control.Controller)) @@ -32,6 +31,8 @@ class TestController(unittest.TestCase): Basic sanity check for the from_socket_file constructor. """ + if test.runner.require_control(self): return + if test.runner.Torrc.SOCKET in test.runner.get_runner().get_options(): with stem.control.Controller.from_socket_file(socket_path = test.runner.CONTROL_SOCKET_PATH) as controller: self.assertTrue(isinstance(controller, stem.control.Controller)) @@ -43,6 +44,8 @@ class TestController(unittest.TestCase): Exercises GETINFO with valid and invalid queries. """ + if test.runner.require_control(self): return + runner = test.runner.get_runner() with runner.get_tor_controller() as controller: @@ -80,6 +83,8 @@ class TestController(unittest.TestCase): Test that the convenient method get_version() works. """ + if test.runner.require_control(self): return + runner = test.runner.get_runner() with runner.get_tor_controller() as controller: version = controller.get_version() @@ -91,6 +96,8 @@ class TestController(unittest.TestCase): Test that the convenient method authenticate() works. """ + if test.runner.require_control(self): return + runner = test.runner.get_runner() with runner.get_tor_controller(False) as controller: controller.authenticate(test.runner.CONTROL_PASSWORD) @@ -101,6 +108,8 @@ class TestController(unittest.TestCase): Test that the convenient method protocolinfo() works. """ + if test.runner.require_control(self): return + runner = test.runner.get_runner() with runner.get_tor_controller(False) as controller: diff --git a/test/integ/descriptor/extrainfo_descriptor.py b/test/integ/descriptor/extrainfo_descriptor.py index 45d1a2b..d960055 100644 --- a/test/integ/descriptor/extrainfo_descriptor.py +++ b/test/integ/descriptor/extrainfo_descriptor.py @@ -144,12 +144,13 @@ k0d2aofcVbHr4fPQOSST0LXDrhFl5Fqo5um296zpJGvRUeO6S44U/EfJAGShtqWw """ # lengthy test and uneffected by targets, so only run once - test.runner.only_run_once(self, "test_cached_descriptor") + if test.runner.only_run_once(self, "test_cached_descriptor"): return descriptor_path = test.runner.get_runner().get_test_dir("cached-extrainfo") if not os.path.exists(descriptor_path): - self.skipTest("(no cached descriptors)") + test.runner.skip(self, "(no cached descriptors)") + return with open(descriptor_path) as descriptor_file: for desc in stem.descriptor.extrainfo_descriptor.parse_file(descriptor_file): diff --git a/test/integ/descriptor/server_descriptor.py b/test/integ/descriptor/server_descriptor.py index 0af3cdf..7a3e2e6 100644 --- a/test/integ/descriptor/server_descriptor.py +++ b/test/integ/descriptor/server_descriptor.py @@ -146,12 +146,13 @@ Qlx9HNCqCY877ztFRC624ja2ql6A2hBcuoYMbkHjcQ4= """ # lengthy test and uneffected by targets, so only run once - test.runner.only_run_once(self, "test_cached_descriptor") + if test.runner.only_run_once(self, "test_cached_descriptor"): return descriptor_path = test.runner.get_runner().get_test_dir("cached-descriptors") if not os.path.exists(descriptor_path): - self.skipTest("(no cached descriptors)") + test.runner.skip(self, "(no cached descriptors)") + return with open(descriptor_path) as descriptor_file: for desc in stem.descriptor.server_descriptor.parse_file(descriptor_file): diff --git a/test/integ/process.py b/test/integ/process.py index 61440fd..e3dd277 100644 --- a/test/integ/process.py +++ b/test/integ/process.py @@ -15,7 +15,7 @@ class TestProcess(unittest.TestCase): Exercises launch_tor_with_config. """ - test.runner.only_run_once(self, "test_launch_tor_with_config") + if test.runner.only_run_once(self, "test_launch_tor_with_config"): return # Launch tor without a torrc, but with a control port. Confirms that this # works by checking that we're still able to access the new instance. @@ -44,7 +44,7 @@ class TestProcess(unittest.TestCase): Runs launch_tor where it times out before completing. """ - test.runner.only_run_once(self, "test_launch_tor_with_timeout") + if test.runner.only_run_once(self, "test_launch_tor_with_timeout"): return start_time = time.time() self.assertRaises(OSError, stem.process.launch_tor_with_config, {'SocksPort': '2777'}, "tor", 100, None, 2) diff --git a/test/integ/response/protocolinfo.py b/test/integ/response/protocolinfo.py index a80f406..4f13e7b 100644 --- a/test/integ/response/protocolinfo.py +++ b/test/integ/response/protocolinfo.py @@ -17,7 +17,6 @@ from test.integ.util.system import filter_system_call class TestProtocolInfo(unittest.TestCase): def setUp(self): - test.runner.require_control(self) mocking.mock(stem.util.proc.is_available, mocking.return_false()) mocking.mock(stem.util.system.is_available, mocking.return_true()) @@ -30,6 +29,8 @@ class TestProtocolInfo(unittest.TestCase): connection. """ + if test.runner.require_control(self): return + control_socket = test.runner.get_runner().get_tor_socket(False) control_socket.send("PROTOCOLINFO 1") protocolinfo_response = control_socket.recv() @@ -56,6 +57,8 @@ class TestProtocolInfo(unittest.TestCase): with the 'RELATIVE' target. """ + if test.runner.require_control(self): return + if test.runner.Torrc.PORT in test.runner.get_runner().get_options(): cwd_by_port_lookup_prefixes = ( stem.util.system.GET_PID_BY_PORT_NETSTAT, @@ -89,6 +92,8 @@ class TestProtocolInfo(unittest.TestCase): re-establish it. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket(False) as control_socket: for i in range(5): protocolinfo_response = stem.connection.get_protocolinfo(control_socket) @@ -100,6 +105,8 @@ class TestProtocolInfo(unittest.TestCase): already disconnected it. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket(False) as control_socket: # makes a couple protocolinfo queries outside of get_protocolinfo first control_socket.send("PROTOCOLINFO 1") diff --git a/test/integ/socket/control_message.py b/test/integ/socket/control_message.py index 1578917..cb2fe52 100644 --- a/test/integ/socket/control_message.py +++ b/test/integ/socket/control_message.py @@ -12,14 +12,13 @@ import stem.version import test.runner class TestControlMessage(unittest.TestCase): - def setUp(self): - test.runner.require_control(self) - def test_unestablished_socket(self): """ Checks message parsing when we have a valid but unauthenticated socket. """ + if test.runner.require_control(self): return + # If an unauthenticated connection gets a message besides AUTHENTICATE or # PROTOCOLINFO then tor will give an 'Authentication required.' message and # hang up. @@ -60,6 +59,8 @@ class TestControlMessage(unittest.TestCase): Parses the response for a command which doesn't exist. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket() as control_socket: control_socket.send("blarg") unrecognized_command_response = control_socket.recv() @@ -73,6 +74,8 @@ class TestControlMessage(unittest.TestCase): Parses the response for a GETINFO query which doesn't exist. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket() as control_socket: control_socket.send("GETINFO blarg") unrecognized_key_response = control_socket.recv() @@ -86,6 +89,8 @@ class TestControlMessage(unittest.TestCase): Parses the 'GETINFO config-file' response. """ + if test.runner.require_control(self): return + runner = test.runner.get_runner() torrc_dst = runner.get_torrc_path() @@ -102,7 +107,11 @@ class TestControlMessage(unittest.TestCase): Parses the 'GETINFO config-text' response. """ - test.runner.require_version(self, stem.version.Requirement.GETINFO_CONFIG_TEXT) + if test.runner.require_control(self): + return + elif test.runner.require_version(self, stem.version.Requirement.GETINFO_CONFIG_TEXT): + return + runner = test.runner.get_runner() # We can't be certain of the order, and there may be extra config-text @@ -143,6 +152,8 @@ class TestControlMessage(unittest.TestCase): Issues 'SETEVENTS BW' and parses a couple events. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket() as control_socket: control_socket.send("SETEVENTS BW") setevents_response = control_socket.recv() diff --git a/test/integ/socket/control_socket.py b/test/integ/socket/control_socket.py index 1f06027..2e81599 100644 --- a/test/integ/socket/control_socket.py +++ b/test/integ/socket/control_socket.py @@ -18,14 +18,13 @@ import stem.socket import test.runner class TestControlSocket(unittest.TestCase): - def setUp(self): - test.runner.require_control(self) - def test_send_buffered(self): """ Sends multiple requests before receiving back any of the replies. """ + if test.runner.require_control(self): return + runner = test.runner.get_runner() tor_version = runner.get_tor_version() @@ -43,6 +42,8 @@ class TestControlSocket(unittest.TestCase): Sends a message after we've closed the connection. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket() as control_socket: self.assertTrue(control_socket.is_alive()) control_socket.close() @@ -60,6 +61,8 @@ class TestControlSocket(unittest.TestCase): call. With a file socket, however, we'll also fail when calling send(). """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket() as control_socket: control_socket.send("QUIT") self.assertEquals("closing connection", str(control_socket.recv())) @@ -80,6 +83,8 @@ class TestControlSocket(unittest.TestCase): Receives a message after we've closed the connection. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket() as control_socket: self.assertTrue(control_socket.is_alive()) control_socket.close() @@ -93,6 +98,8 @@ class TestControlSocket(unittest.TestCase): end. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket() as control_socket: control_socket.send("QUIT") self.assertEquals("closing connection", str(control_socket.recv())) @@ -110,6 +117,8 @@ class TestControlSocket(unittest.TestCase): Checks that we can reconnect, use, and disconnect a socket repeatedly. """ + if test.runner.require_control(self): return + with test.runner.get_runner().get_tor_socket(False) as control_socket: for i in range(10): # this will raise if the PROTOCOLINFO query fails diff --git a/test/integ/util/system.py b/test/integ/util/system.py index 607d9f7..60703e9 100644 --- a/test/integ/util/system.py +++ b/test/integ/util/system.py @@ -79,7 +79,8 @@ class TestSystem(unittest.TestCase): """ if self.is_extra_tor_running: - self.skipTest("(multiple tor instances)") + test.runner.skip(self, "(multiple tor instances)") + return tor_pid = test.runner.get_runner().get_pid() self.assertEquals(tor_pid, stem.util.system.get_pid_by_name("tor")) @@ -91,9 +92,11 @@ class TestSystem(unittest.TestCase): """ if self.is_extra_tor_running: - self.skipTest("(multiple tor instances)") + test.runner.skip(self, "(multiple tor instances)") + return elif not stem.util.system.is_available("pgrep"): - self.skipTest("(pgrep unavailable)") + test.runner.skip(self, "(pgrep unavailable)") + return pgrep_prefix = stem.util.system.GET_PID_BY_NAME_PGREP % "" mocking.mock(stem.util.system.call, filter_system_call([pgrep_prefix])) @@ -107,9 +110,11 @@ class TestSystem(unittest.TestCase): """ if self.is_extra_tor_running: - self.skipTest("(multiple tor instances)") + test.runner.skip(self, "(multiple tor instances)") + return elif not stem.util.system.is_available("pidof"): - self.skipTest("(pidof unavailable)") + test.runner.skip(self, "(pidof unavailable)") + return pidof_prefix = stem.util.system.GET_PID_BY_NAME_PIDOF % "" mocking.mock(stem.util.system.call, filter_system_call([pidof_prefix])) @@ -123,11 +128,14 @@ class TestSystem(unittest.TestCase): """ if self.is_extra_tor_running: - self.skipTest("(multiple tor instances)") + test.runner.skip(self, "(multiple tor instances)") + return elif not stem.util.system.is_available("ps"): - self.skipTest("(ps unavailable)") + test.runner.skip(self, "(ps unavailable)") + return elif stem.util.system.is_bsd(): - self.skipTest("(linux only)") + test.runner.skip(self, "(linux only)") + return ps_prefix = stem.util.system.GET_PID_BY_NAME_PS_LINUX % "" mocking.mock(stem.util.system.call, filter_system_call([ps_prefix])) @@ -141,11 +149,14 @@ class TestSystem(unittest.TestCase): """ if self.is_extra_tor_running: - self.skipTest("(multiple tor instances)") + test.runner.skip(self, "(multiple tor instances)") + return elif not stem.util.system.is_available("ps"): - self.skipTest("(ps unavailable)") + test.runner.skip(self, "(ps unavailable)") + return elif not stem.util.system.is_bsd(): - self.skipTest("(bsd only)") + test.runner.skip(self, "(bsd only)") + return ps_prefix = stem.util.system.GET_PID_BY_NAME_PS_BSD mocking.mock(stem.util.system.call, filter_system_call([ps_prefix])) @@ -160,11 +171,14 @@ class TestSystem(unittest.TestCase): runner = test.runner.get_runner() if self.is_extra_tor_running: - self.skipTest("(multiple tor instances)") + test.runner.skip(self, "(multiple tor instances)") + return elif not stem.util.system.is_available("lsof"): - self.skipTest("(lsof unavailable)") + test.runner.skip(self, "(lsof unavailable)") + return elif not runner.is_ptraceable(): - self.skipTest("(DisableDebuggerAttachment is set)") + test.runner.skip(self, "(DisableDebuggerAttachment is set)") + return lsof_prefix = stem.util.system.GET_PID_BY_NAME_LSOF % "" mocking.mock(stem.util.system.call, filter_system_call([lsof_prefix])) @@ -179,9 +193,11 @@ class TestSystem(unittest.TestCase): runner = test.runner.get_runner() if not _has_port(): - self.skipTest("(test instance has no port)") + test.runner.skip(self, "(test instance has no port)") + return elif not runner.is_ptraceable(): - self.skipTest("(DisableDebuggerAttachment is set)") + test.runner.skip(self, "(DisableDebuggerAttachment is set)") + return tor_pid, tor_port = runner.get_pid(), test.runner.CONTROL_PORT self.assertEquals(tor_pid, stem.util.system.get_pid_by_port(tor_port)) @@ -194,13 +210,17 @@ class TestSystem(unittest.TestCase): runner = test.runner.get_runner() if not _has_port(): - self.skipTest("(test instance has no port)") + test.runner.skip(self, "(test instance has no port)") + return elif not stem.util.system.is_available("netstat"): - self.skipTest("(netstat unavailable)") + test.runner.skip(self, "(netstat unavailable)") + return elif stem.util.system.is_bsd(): - self.skipTest("(linux only)") + test.runner.skip(self, "(linux only)") + return elif not runner.is_ptraceable(): - self.skipTest("(DisableDebuggerAttachment is set)") + test.runner.skip(self, "(DisableDebuggerAttachment is set)") + return netstat_prefix = stem.util.system.GET_PID_BY_PORT_NETSTAT mocking.mock(stem.util.system.call, filter_system_call([netstat_prefix])) @@ -215,13 +235,17 @@ class TestSystem(unittest.TestCase): runner = test.runner.get_runner() if not _has_port(): - self.skipTest("(test instance has no port)") + test.runner.skip(self, "(test instance has no port)") + return elif not stem.util.system.is_available("sockstat"): - self.skipTest("(sockstat unavailable)") + test.runner.skip(self, "(sockstat unavailable)") + return elif not stem.util.system.is_bsd(): - self.skipTest("(bsd only)") + test.runner.skip(self, "(bsd only)") + return elif not runner.is_ptraceable(): - self.skipTest("(DisableDebuggerAttachment is set)") + test.runner.skip(self, "(DisableDebuggerAttachment is set)") + return sockstat_prefix = stem.util.system.GET_PID_BY_PORT_SOCKSTAT % "" mocking.mock(stem.util.system.call, filter_system_call([sockstat_prefix])) @@ -236,11 +260,14 @@ class TestSystem(unittest.TestCase): runner = test.runner.get_runner() if not _has_port(): - self.skipTest("(test instance has no port)") + test.runner.skip(self, "(test instance has no port)") + return elif not stem.util.system.is_available("lsof"): - self.skipTest("(lsof unavailable)") + test.runner.skip(self, "(lsof unavailable)") + return elif not runner.is_ptraceable(): - self.skipTest("(DisableDebuggerAttachment is set)") + test.runner.skip(self, "(DisableDebuggerAttachment is set)") + return lsof_prefix = stem.util.system.GET_PID_BY_PORT_LSOF mocking.mock(stem.util.system.call, filter_system_call([lsof_prefix])) @@ -254,7 +281,9 @@ class TestSystem(unittest.TestCase): """ # on macs this test is unreliable because Quicklook sometimes claims '/tmp' - if os.uname()[0] == "Darwin": self.skipTest("(unreliable due to Quicklook)") + if os.uname()[0] == "Darwin": + test.runner.skip(self, "(unreliable due to Quicklook)") + return # we're not running with a control socket so this just exercises the # failure case @@ -270,7 +299,8 @@ class TestSystem(unittest.TestCase): runner = test.runner.get_runner() if not runner.is_ptraceable(): - self.skipTest("(DisableDebuggerAttachment is set)") + test.runner.skip(self, "(DisableDebuggerAttachment is set)") + return runner_pid, tor_cwd = runner.get_pid(), runner.get_tor_cwd() self.assertEquals(tor_cwd, stem.util.system.get_cwd(runner_pid)) @@ -283,9 +313,11 @@ class TestSystem(unittest.TestCase): runner = test.runner.get_runner() if not stem.util.system.is_available("pwdx"): - self.skipTest("(pwdx unavailable)") + test.runner.skip(self, "(pwdx unavailable)") + return elif not runner.is_ptraceable(): - self.skipTest("(DisableDebuggerAttachment is set)") + test.runner.skip(self, "(DisableDebuggerAttachment is set)") + return # filter the call function to only allow this command pwdx_prefix = stem.util.system.GET_CWD_PWDX % "" @@ -301,9 +333,11 @@ class TestSystem(unittest.TestCase): runner = test.runner.get_runner() if not stem.util.system.is_available("lsof"): - self.skipTest("(lsof unavailable)") + test.runner.skip(self, "(lsof unavailable)") + return elif not runner.is_ptraceable(): - self.skipTest("(DisableDebuggerAttachment is set)") + test.runner.skip(self, "(DisableDebuggerAttachment is set)") + return # filter the call function to only allow this command lsof_prefix = "lsof -a -p " diff --git a/test/integ/version.py b/test/integ/version.py index 906edbc..34edec9 100644 --- a/test/integ/version.py +++ b/test/integ/version.py @@ -5,6 +5,7 @@ running with. import unittest +import stem.prereq import test.runner import stem.version @@ -15,7 +16,8 @@ class TestVersion(unittest.TestCase): """ if not stem.util.system.is_available("tor"): - self.skipTest("(tor isn't in our path)") + test.runner.skip(self, "(tor isn't in our path)") + return # Since tor is in our path we should expect to be able to get the version # that way, though this might not belong to our test instance (if we're @@ -35,7 +37,7 @@ class TestVersion(unittest.TestCase): test instance provides. """ - test.runner.require_control(self) + if test.runner.require_control(self): return runner = test.runner.get_runner() system_tor_version = stem.version.get_system_tor_version(runner.get_tor_command()) @@ -47,7 +49,7 @@ class TestVersion(unittest.TestCase): we can parse it. """ - test.runner.require_control(self) + if test.runner.require_control(self): return control_socket = test.runner.get_runner().get_tor_socket() control_socket.send("GETINFO version") diff --git a/test/runner.py b/test/runner.py index 7d053cb..1bf1860 100644 --- a/test/runner.py +++ b/test/runner.py @@ -8,6 +8,7 @@ about the tor test instance they're running against. RunnerStopped - Runner doesn't have an active tor instance TorInaccessable - Tor can't be queried for the information + skip - skips the current test if we can require_control - skips the test unless tor provides a controller endpoint require_version - skips the test unless we meet a tor version requirement exercise_controller - basic sanity check that a controller connection can be used @@ -44,6 +45,7 @@ import logging import tempfile import threading +import stem.prereq import stem.socket import stem.process import stem.version @@ -99,15 +101,31 @@ class RunnerStopped(Exception): class TorInaccessable(Exception): "Raised when information is needed from tor but the instance we have is inaccessable" +def skip(test_case, message): + """ + Skips the test if we can. The capability for skipping tests was added in + python 2.7 so callers should return after this, so they report 'success' if + this method is unavailable. + + :param unittest.TestCase test_case: test being ran + :param str message: message to skip the test with + """ + + if stem.prereq.is_python_27(): + test_case.skipTest(message) + def require_control(test_case): """ Skips the test unless tor provides an endpoint for controllers to attach to. :param unittest.TestCase test_case: test being ran + + :returns: True if test should be skipped, False otherwise """ if not test.runner.get_runner().is_accessible(): - test_case.skipTest("(no connection)") + skip(test_case, "(no connection)") + return True def require_version(test_case, req_version): """ @@ -115,10 +133,13 @@ def require_version(test_case, req_version): :param unittest.TestCase test_case: test being ran :param stem.version.Version req_version: required tor version for the test + + :returns: True if test should be skipped, False otherwise """ if get_runner().get_tor_version() < req_version: - test_case.skipTest("(requires %s)" % req_version) + skip(test_case, "(requires %s)" % req_version) + return True def only_run_once(test_case, test_name): """ @@ -128,10 +149,13 @@ def only_run_once(test_case, test_name): :param unittest.TestCase test_case: test being ran :param str test_name: name of the test being ran + + :returns: True if test should be skipped, False otherwise """ if (test_case, test_name) in RAN_TESTS: - test_case.skipTest("(already ran)") + skip(test_case, "(already ran)") + return True else: RAN_TESTS.append((test_case, test_name)) diff --git a/test/unit/descriptor/server_descriptor.py b/test/unit/descriptor/server_descriptor.py index 8502b56..2e642af 100644 --- a/test/unit/descriptor/server_descriptor.py +++ b/test/unit/descriptor/server_descriptor.py @@ -9,6 +9,7 @@ import unittest import stem.prereq import stem.descriptor.server_descriptor from stem.descriptor.server_descriptor import RelayDescriptor, BridgeDescriptor +import test.runner CRYPTO_BLOB = """ MIGJAoGBAJv5IIWQ+WDWYUdyA/0L8qbIkEVH/cwryZWoIaPAzINfrw1WfNZGtBmg @@ -314,7 +315,8 @@ class TestServerDescriptor(unittest.TestCase): """ if not stem.prereq.is_rsa_available(): - self.skipTest("(rsa module unavailable)") + test.runner.skip(self, "(rsa module unavailable)") + return fingerprint = "4F0C 867D F0EF 6816 0568 C826 838F 482C EA7C FE44" desc_text = _make_descriptor({"opt fingerprint": fingerprint}) @@ -328,7 +330,8 @@ class TestServerDescriptor(unittest.TestCase): """ if not stem.prereq.is_rsa_available(): - self.skipTest("(rsa module unavailable)") + test.runner.skip(self, "(rsa module unavailable)") + return fingerprint = "4F0C 867D F0EF 6816 0568 C826 838F 482C EA7C FE45" desc_text = _make_descriptor({"opt fingerprint": fingerprint})

1 0

[onionoo/master] Tweak build file.
by karsten＠torproject.org 19 Jun '12

19 Jun '12

commit ef440300dce0fc7a75c1aaff78cd040b41cd4f58 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jun 19 15:16:09 2012 +0200 Tweak build file. --- build.xml | 15 +++++---------- 1 files changed, 5 insertions(+), 10 deletions(-) diff --git a/build.xml b/build.xml index 2cc64d0..770fbf0 100644 --- a/build.xml +++ b/build.xml @@ -13,12 +13,9 @@ <property name="warfile" value="onionoo.war"/> <path id="classpath"> <pathelement path="${classes}"/> - <pathelement location="lib/commons-codec-1.4.jar"/> - <pathelement location="lib/commons-lang-2.5.jar"/> - <pathelement location="lib/commons-compress-1.3.jar"/> - <pathelement location="lib/servlet-api.jar"/> - <pathelement location="lib/descriptor.jar"/> - <pathelement location="lib/maxmindgeoip.jar"/> + <fileset dir="${libs}"> + <include name="*.jar"/> + </fileset> </path> <target name="init"> <copy file="${contextxmltemplate}" tofile="${contextxml}"/> @@ -36,9 +33,7 @@ optimize="false" failonerror="true" includeantruntime="false"> - <classpath> - <fileset dir="${libs}"/> - </classpath> + <classpath refid="classpath"/> </javac> </target> <target name="war" @@ -58,7 +53,7 @@ </target> <target name="run" depends="compile"> <java fork="true" - maxmemory="4096m" + maxmemory="2048m" classname="org.torproject.onionoo.Main"> <classpath refid="classpath"/> </java>

1 0

[metrics-lib/master] Fix unit tests which were broken in 466725e.
by karsten＠torproject.org 19 Jun '12

19 Jun '12

commit 7348b3d208fb7f1e70a123712792b2561eb4930d Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jun 19 14:11:34 2012 +0200 Fix unit tests which were broken in 466725e. --- .../descriptor/impl/ServerDescriptorImplTest.java | 14 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/test/org/torproject/descriptor/impl/ServerDescriptorImplTest.java b/test/org/torproject/descriptor/impl/ServerDescriptorImplTest.java index a59db3b..264ff13 100644 --- a/test/org/torproject/descriptor/impl/ServerDescriptorImplTest.java +++ b/test/org/torproject/descriptor/impl/ServerDescriptorImplTest.java @@ -579,8 +579,20 @@ public class ServerDescriptorImplTest { } @Test(expected = DescriptorParseException.class) + public void testBandwidthOneValue() throws DescriptorParseException { + DescriptorBuilder.createWithBandwidthLine("bandwidth 51200"); + } + + @Test() public void testBandwidthTwoValues() throws DescriptorParseException { - DescriptorBuilder.createWithBandwidthLine("bandwidth 51200 51200"); + /* This is allowed, because Tor versions 0.0.8 and older only wrote + * bandwidth lines with rate and burst values, but no observed + * value. */ + ServerDescriptor descriptor = DescriptorBuilder. + createWithBandwidthLine("bandwidth 51200 51200"); + assertEquals(51200, (int) descriptor.getBandwidthRate()); + assertEquals(51200, (int) descriptor.getBandwidthBurst()); + assertEquals(-1, (int) descriptor.getBandwidthObserved()); } @Test(expected = DescriptorParseException.class)

1 0

[metrics-lib/master] Tweak build file a bit.
by karsten＠torproject.org 19 Jun '12

19 Jun '12

commit 2c3e59bb71b8f66109da362148853c932cdf71cb Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jun 19 14:36:44 2012 +0200 Tweak build file a bit. --- build.xml | 15 ++++++--------- 1 files changed, 6 insertions(+), 9 deletions(-) diff --git a/build.xml b/build.xml index 0f2539a..e11d3fd 100644 --- a/build.xml +++ b/build.xml @@ -1,12 +1,13 @@ -<project default="run" name="descriptor" basedir="."> +<project default="jar" name="descriptor" basedir="."> <property name="sources" value="src"/> <property name="classes" value="classes"/> <property name="tests" value="test"/> <property name="libs" value="lib"/> <path id="classpath"> <pathelement path="${classes}"/> - <pathelement location="lib/commons-codec-1.4.jar"/> - <pathelement location="lib/junit-4.8.2.jar"/> + <fileset dir="${libs}"> + <include name="*.jar"/> + </fileset> </path> <target name="init"> <mkdir dir="${classes}"/> @@ -22,9 +23,7 @@ optimize="false" failonerror="true" includeantruntime="false"> - <classpath> - <fileset dir="${libs}"/> - </classpath> + <classpath refid="classpath"/> </javac> </target> <target name="jar" depends="compile"> @@ -41,9 +40,7 @@ optimize="false" failonerror="true" includeantruntime="false"> - <classpath> - <fileset dir="${libs}"/> - </classpath> + <classpath refid="classpath"/> </javac> <junit fork="true" haltonfailure="true" printsummary="off"> <classpath refid="classpath"/>

1 0

[metrics-web/master] Fix missing values in direct users graphs.
by karsten＠torproject.org 19 Jun '12

19 Jun '12

commit f00cfbe8f43d851b5e7a1f32336b20880e312cb6 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jun 19 08:56:50 2012 +0200 Fix missing values in direct users graphs. When we didn't have a single directory mirror reporting requests from a given country, we treated these dates as "don't have any data" and interrupted drawing the line. This makes sense for times when there was a general problem with statistics gathering in the network; we wouldn't want all graphs to drop to zero in that case. But if there was no such network-wide event, we could interpret "no data for that country, but lots of data for other countries" as "no users from that country" and continue drawing the line at 0 users. Fixes the rest of #6170. --- rserve/graphs.R | 16 ++++++++++++---- 1 files changed, 12 insertions(+), 4 deletions(-) diff --git a/rserve/graphs.R b/rserve/graphs.R index 30413b8..41dd22b 100644 --- a/rserve/graphs.R +++ b/rserve/graphs.R @@ -656,26 +656,34 @@ plot_direct_users <- function(start, end, country, events, path, nocutoff, dpi) { drv <- dbDriver("PostgreSQL") con <- dbConnect(drv, user = dbuser, password = dbpassword, dbname = db) - q <- paste("SELECT date, r, bwp, brn, bwn, brp, bwr, brr ", + q <- paste("SELECT date, r, bwp, brn, bwn, brp, bwr, brr, country ", "FROM user_stats WHERE date >= '", start, "' AND date <= '", end, "' ", ifelse(nocutoff == "off", " AND date < (SELECT MAX(date) FROM user_stats) - 1 ", ""), - " AND country = '", ifelse(country == "all", "zy", country), "'", - sep = "") + " AND (country = 'zy'", ifelse(country == "all", "", + paste(" OR country = '", country, "'", sep = "")), ")", sep = "") rs <- dbSendQuery(con, q) u <- fetch(rs, n = -1) dbDisconnect(con) dbUnloadDriver(drv) + a <- u[u$country == "zy", ] + if (country != "all") + u <- u[u$country == country, ] u <- data.frame(date = u$date, users = u$r * (u$bwp * u$brn / u$bwn - u$brp) / (u$bwr * u$brn / u$bwn - u$brr) / 10) dates <- seq(from = as.Date(start, "%Y-%m-%d"), to = as.Date(end, "%Y-%m-%d"), by="1 day") - missing <- setdiff(dates, u$date) + missing <- setdiff(dates, a$date) if (length(missing) > 0) u <- rbind(u, data.frame(date = as.Date(missing, origin = "1970-01-01"), users = NA)) + missing <- setdiff(dates, u$date) + if (length(missing) > 0) + u <- rbind(u, + data.frame(date = as.Date(missing, origin = "1970-01-01"), + users = 0)) title <- ifelse(country == "all", "Directly connecting users from all countries\n", paste("Directly connecting users from ", countryname(country), "\n",

1 0

[metrics-web/master] Fix direct users graph showing censorship events.
by karsten＠torproject.org 19 Jun '12

19 Jun '12

commit 3ad9bb84db872d07ed571e9b094f09e1abf7eb45 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Jun 19 08:09:30 2012 +0200 Fix direct users graph showing censorship events. The problem was that a graph that didn't have *any* upturns or downturns showed these events for *every* single data point. R/ggplot2 sure can do unexpected things. Fixes (part of) #6170. --- rserve/graphs.R | 12 ++++++++---- 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/rserve/graphs.R b/rserve/graphs.R index f5575c3..30413b8 100644 --- a/rserve/graphs.R +++ b/rserve/graphs.R @@ -696,10 +696,14 @@ plot_direct_users <- function(start, end, country, events, path, nocutoff, downturns <- r[r$users < r$minusers, 1:2] plot <- plot + geom_ribbon(data = r, aes(ymin = minusers, ymax = maxusers), - fill = "gray") + - geom_point(data = upturns, aes(x = date, y = users), size = 5, - colour = "dodgerblue2") + - geom_point(data = downturns, aes(x = date, y = users), size = 5, + fill = "gray") + if (length(upturns$date) > 0) + plot <- plot + + geom_point(data = upturns, aes(x = date, y = users), size = 5, + colour = "dodgerblue2") + if (length(downturns$date) > 0) + plot <- plot + + geom_point(data = downturns, aes(x = date, y = users), size = 5, colour = "firebrick2") } plot <- plot +

1 0

r25680: {website} add BBC story from last week. (website/trunk/press/en)
by Andrew Lewman 18 Jun '12

18 Jun '12

Author: phobos Date: 2012-06-18 21:39:34 +0000 (Mon, 18 Jun 2012) New Revision: 25680 Modified: website/trunk/press/en/inthemedia.wml Log: add BBC story from last week. Modified: website/trunk/press/en/inthemedia.wml =================================================================== --- website/trunk/press/en/inthemedia.wml 2012-06-18 18:12:14 UTC (rev 25679) +++ website/trunk/press/en/inthemedia.wml 2012-06-18 21:39:34 UTC (rev 25680) @@ -32,16 +32,21 @@ <th>Topic</th> </tr> </thead> -<tr style="background-color: #e5e5e5;"> +<tr> <td>2012 Jun 18</td> <td>Poynter</td> <td><a href="http://www.poynter.org/latest-news/top-stories/177642/news-challenge-funds-…">News Challenge funds 6 projects focused on networks</td> </tr> -<tr> +<tr style="background-color: #e5e5e5;"> <td>2012 Jun 18</td> <td>Knight Foundation</td> <td><a href="http://www.knightfoundation.org/grants/20121802/">Knight Foundation funds project to protect journalists and their sources worldwide by providing them with a toolkit to preserve their anonymity online.</td> </tr> +<tr> +<td>2012 Jun 15</td> +<td>BBC</td> +<td><a href="http://www.bbc.co.uk/news/technology-18461292">Ethiopia clamps down on Skype and other internet use on Tor</td> +</tr> <tr style="background-color: #e5e5e5;"> <td>2012 Apr 30</td> <td>Forbes</td>

1 0

[censorship-timeline/master] add a note about two patches that worked in kazakhstan
by runa＠torproject.org 18 Jun '12

18 Jun '12

commit 3b09a1571c67f53dc81533c81f99cfadfd550d26 Author: Runa A. Sandvik <runa.sandvik(a)gmail.com> Date: Mon Jun 18 20:24:35 2012 +0100 add a note about two patches that worked in kazakhstan --- patches/kazakhstan/notes.txt | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/patches/kazakhstan/notes.txt b/patches/kazakhstan/notes.txt new file mode 100644 index 0000000..0aa68ac --- /dev/null +++ b/patches/kazakhstan/notes.txt @@ -0,0 +1,8 @@ +As described in #6045, we found that changing the cipher suite (from the +default TLS1_TXT_DHE_RSA_WITH_AES_256_SHA (0x0039)) bypasses the +censorship in Kazakhstan. The patch ethiopia/remove_0x0039.patch removes +0x0039 from SERVER_CIPHER_LIST. + +The patch ethiopia/finalhello_skip.patch causes the final hello done TLS +record to be sent in a separate packet. This also bypasses the +censorship in Kazakhstan.

1 0

← Newer
1
...
35
36
37
38
39
40
41
...
88
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits June 2012