tor-dev June 2012

tor-dev@lists.torproject.org

37 participants
46 discussions

Re: [tor-dev] Stem Testing Mocking Issue
by Damian Johnson 19 Jun '12

19 Jun '12

> The changes look great! I see no issues with merging to the master branch. Great, pushed. > Sorry about the reStructuredText inconvenience. I actually didn't even think of it -- I just meant to clean up the comments a bit, but I'll definitely be more careful in the future. No worries. Again, it would usually have been a welcome change. :) > Once we confirm this with Damian, he will push the changes to master > in torprojects' repository. Don't worry about that. The way that … [View More]open source git projects usually work is that you make a 'pull request', which simply means saying 'I have some changes that I would like to share, here they are' (which is what you've been doing). If the changes look good then I'll rebase them onto the master branch and push them myself. Usually only a tiny number of central developers actually have push access to the master repository. > Our code can be found at: > > https://github.com/meganchang/Stem/blob/proc-tests/test/unit/util/proc.py Ok. Previously I was pulling from 'jacthinman', is 'meganchang' the github repository where you plan to do most of your future work? I'd suggest periodically running the following, replacing 'origin' with whatever you're calling the torproject master remote... git fetch origin git rebase origin/master That way your changes don't fall too far out of date with the current HEAD (looks like you're currently 29 commits behind). > +import test.unit.util.proc Please keep the order of the current imports (the unit/integ test imports are batched together). > + test.unit.util.proc.TestProc, Lets move this test just above the "test.unit.util.system.TestSystem". The tests are ordered by their dependencies so that the lowest-level stuff runs first. The reason for that is that if, say, stem.util.enum breaks then it'll probably break just about everything else so we want to report those errors first (rather than leave the developer wondering why something like stem.connection was also broken). > + prefix_list = sorted(list(line_prefixes)) The extra list wrapper isn't necessary. >>> sorted((1, 4, 2)) [1, 2, 4] > Let us know what you think about our unit tests thus far! We also wanted to let you know that we plan on finishing all proc unit tests by Tuesday (June 19), and all proc integration tests by Friday (June 22). Great! What you have so far looks good, looking forward to seeing the rest. Be warned that, as Ravi can attest, code reviews generally take a few iterations. Here's an example... https://trac.torproject.org/5262 Cheers! -Damian [View Less]

2 4

[GSoC] Tails Server
by jvoisin 19 Jun '12

19 Jun '12

Hello everyone. I am sorry but I won't be able to pursue/achieve my GSoC[1] for personal reasons that I prefer not disclose on a public mailing list. I'll donate my current payment to the Tor project. I am really sorry about this; I hope that I haven't took someone else's place, and that this project will be achieved. Take care, 1. https://tails.boum.org/todo/server_edition/ -- jvoisin

2 1

[GSoC] Stem controller class
by Ravi Chandra Padmala 17 Jun '12

17 Jun '12

Hello I have been working on the general controller class. I'm getting ever closer to having the getconf parsing code[1] merged into master. While implementing that, we came across a bug. Currently Tor doesn't quote it's responses to a getconf request[2]. I am also working on the other control command parsing implementations specified in my proposal[3]. Currently working on the SETCONF/RESETCONF methods. There isn't much else to report at the moment. Note: I'm still behind schedule. But, … [View More]

1 0

[GSoC] Status update - Stegotorus
by vmon 17 Jun '12

17 Jun '12

Hello Devers, This is my first status update. I wanted to send one after my intro but first, it wasn't clear for me where I should setup my git and then I had few (ok two but it's still too much) hard drive failures. So here is the long combined version of first two update (Sorry :-S ) 1 . So when first I got Stegotorus and I managed to compile it with few modification required by gcc 4.7. [1]. It did not function practically on my computer. Some data was being exchanged between client and … [View More]server but I was not able to browse any page. I spent few days to figure out the problem. It wasn't easy for various obvious reasons. I forced limiting the number of connections, and that made it semi-functional able to browse simple pages. Eventually, it turned out, that it was known bug and I got the patch and it started working without problem. 2. My second task was to find a http proxy code, that I can use to implement different http modifications that Stegotorus protocol should be able to handle. I looked into the code of few proxies including Polipo, shim, privoxy, ziproxy. Polipo and shim had a simpler code but each had its own problem. Meanwhile, I tested Stegotorus upon Polipo and confirmed that its traffic doesn't survive Polipo's proxying. I decided to start with much simpler proxy. First started to implement one using twisted, but I found a sample proxy as a part of libevent code which finally, I decided to use for my tests. Next step, I integrated the proxy code to Stegotorus code. I also added a simple proxy test to the set of unitary tests of Stegotorus. I confirm it failed. 3. I spent some time reading following papers on the effects of weekly configured (security-wise) / evil http proxies on http(s) traffic, to get some insight in http proxy role: * Talking o yourself for fun and profit. * Pretty-Bad-Proxy: An overlooked adversary in browsers' HTTPS deployments. * Divide and Conquer: HTTP response splitting, web cache poisoning attacks, and related topics. It was while we were waiting for Stegotorus code to become public. 4. I spend last week, to debug the problem with Stegotorus and libevent sample proxy. After, sharing my finding with Zack, it turned out that the proxy cannot handle the situation when one side, shuts down the buffer for writing but still reads from it. So, I modified the proxy code [3] and now Stegotorus passes the proxy test. During coming two weeks, I'm going through the steg protocol code and tries to improve the code, following Zack's advice. Also, I'll try to implement more sophisticated proxy test, like one that involves header manipulation. Sorry for the long update. It was like a 6 week report. Next one will be much shorter. Stay tuned and enjoy the June! vmon 1. https://github.com/vmon/stegotorus/commit/2f3932c433f743fd8bee54fffb75e565a… 2. https://github.com/vmon/stegotorus/commit/9267db9d5d6d2c3ea959d30e1b8434012… 3. https://github.com/vmon/stegotorus/commit/f86479782b27385d92679acaae8802ade… [View Less]

1 0

[GSoC] pyptlib Status Update
by Brandon Wiley 16 Jun '12

16 Jun '12

Here is the proposed schedule for the project: *Week 1 - pyptlib.config API draft Week 2 - pyptlib.config implementation Week 3 - pyptlib.framework API draft Week 4 - pyptlib.framework implementation Week 5 - pyptlib.transports example implementations (dummy, rot13) and command line options Week 6 - testing and debugging of whole system Week 7 - Refactoring, cleaning, and documentation update Midterm evaluations Week 8 - Dust Week 9 - obfs2 Week 10 - flashproxy Week 11 - Transport refinements … [View More]

1 0

STEM: Tor2csv / Tor2xml / Tor2json ?
by Fabio Pietrosanti (naif) 15 Jun '12

15 Jun '12

Hi, i just would like to provide a suggestion for Stem use (maybe already done), now that it has a powerful cached-consensus/descriptors parsers. Would it possible to provide easy to use command line tools to access Tor's data in the following formats: - csv - xml - json So that anyone requiring to access tor's current network data can easily use a function / script trough a command line tool and get it in easy to be formatted output. That's just a suggestion, but it maybe very useful for … [View More]

2 1

Re: [tor-dev] Stem Testing Mocking Issue
by Damian Johnson 14 Jun '12

14 Jun '12

Hi Megan, thanks for the patch! What is an example of a standard library function with a builtin type? I'd like to exercise the use case that has been causing you trouble. This change has a couple issues, for instance it treats anything with the same name as a builtin like a builtin. It also calls setattr() on standard library functions if you try to mock it a second time. I've pushed an adaptation of your change to the 'mocking' branch of my personal repository... git://git.torproject.org/… [View More]

2 3

start_daemon and finish_daemon
by Zack Weinberg 14 Jun '12

14 Jun '12

Why is the process of going into daemon mode (on Unix) split into two functions, start_daemon and finish_daemon? zw

2 2

Dreamplug trouble
by Linus Nordberg 13 Jun '12

13 Jun '12

Hi, An hour ago I had a beautiful dreamplug laying next to me on my table, booting freedombox, making me happy. Now I have a beautiful dreamplug nicely mounted in a rack in a hall next to me, not booting at all, making me sad. --8<---------------cut here---------------start------------->8--- U-Boot 2011.06-02334-g8f495d9-dirty (May 31 2011 - 02:06:26) Marvell-DreamPlug SoC: Kirkwood 88F6281_A0 CPU running @ 1200Mhz L2 running @ 400Mhz SysClock = 400Mhz , TClock = 200Mhz DRAM: 512 … [View More]

2 1

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 … [View More]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? [View Less]

7 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev June 2012