- tor-dev - lists.torproject.org

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

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

12 Jun '12

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

6 12

[GSoC] Update - Safe cookie support/General controller class for Stem
by Ravi Chandra Padmala 11 Jun '12

11 Jun '12

Hello I have finished working on implementing the safe cookie authentication support for Stem. Damian fixed a few things[1] and merged it into master. I'm now working on implementing the general controller class. GETINFO parsing was implemented by Damian as an example. I've implemented GETCONF parsing[2] for the controller. It's almost done. I'm also going to implement the other methods to handle the remaining control commands allocated to week 2 and 3 in my proposal[3]. Note: I'm behind my … [View More]

1 0

Stem Sphinx Documentation
by Damian Johnson 10 Jun '12

10 Jun '12

Hi Ravi, Beck, and everyone else hacking on stem. I just finished and merged a rewrite of our documentation into reStructuredText. The results are... very pretty. http://www.atagar.com/transfer/tmp/stem_html_12_06_05/ Next I plan to make a landing page for stem, and a cron process which will automatically keep a documentation page up to date with the current git master branch. Some pages that you might find especially relevant... Ravi http://www.atagar.com/transfer/tmp/stem_html_12_06_05/… [View More]

2 4

How (not) to Build a Transport Layer for Anonymity Overlays
by Roger Dingledine 09 Jun '12

09 Jun '12

http://pade12.mytestbed.net/pade12-final6.pdf To be presented this coming Friday in London: http://pade12.mytestbed.net/technicalprogram/ --Roger

1 0

Stem Testing Code Question - Wesleyan Interns
by Erik I Islo 08 Jun '12

08 Jun '12

Hi Damian, Having gotten started looking at some of the testing code from Stem over the last day or so, Megan and I have come up with a question. While both of us are currently on #tor and #tor-dev (as ErikI and MeganC), we figured an email would be best for getting started as we have a bit more to say. In run_tests.py, under the if statement that catches the case of integration tests (line 268), there is a block of code that contains a number of references to 'targets.' To start, could you … [View More]

2 1

Can we stop sanitizing nicknames in bridge descriptors?
by Karsten Loesing 06 Jun '12

06 Jun '12

Hi everybody, we're discussing in #5684 whether we can stop sanitizing nicknames in the bridge descriptors that we publish here: https://metrics.torproject.org/data.html#bridgedesc The sanitizing process is described here: https://metrics.torproject.org/formats.html#bridgedesc When we started making sanitized bridge descriptors available on the metrics website we replaced all contained nicknames with "Unnamed". The reason was that "bridge nicknames might give hints on the location of the … [View More]

5 21

Stats on Amazon bridges
by SiNA Rabbani 06 Jun '12

06 Jun '12

Dear Team, I need to get a count of all the Amazon Tor images running bridges. The reason I need this data is so I can follow-up with acessnow.org about the campaign they are running at: https://www.globalproxycloud.net/ How should I go about that data? All the best, SiNA -- First they ignore you, then they laugh at you, then they fight you, then you win ~ Mahatma Gandhi

2 1

[GSoC]Tails-server
by jvoisin 06 Jun '12

06 Jun '12

Hello, the "community bonding period" is over for quite some time now, but as I have previously said in my application, I (unfortunately) won't be able to start my GSoC until the 8th of June. So far, I managed to build Tails in a virtual machine, in a tmpfs, using a proxy (to avoid spamming Debian's mirrors); but also using vagrant[1]. It takes me only a couple of minutes to build Tails on my machine, which is a good news. About the testing environment now: It seems like liveCD testing is not … [View More]

2 1

Stegotorus now available from gitweb.torproject.org
by Zack Weinberg 05 Jun '12

05 Jun '12

On Mon, Jun 4, 2012 at 8:21 AM, Zack Weinberg <zackw(a)panix.com> wrote: > For the moment, the source tree is visible on Github: > <https://github.com/zackw/stegotorus>. It is likely to move to > gitweb.torproject.org hosting in the near future. You can now clone {git,https}://git.torproject.org/stegotorus.git . Be warned that due to a couple of very large files, a clone requires approximately 350MB of disk space and 140MB transferred over the network. (The … [View More]

2 3

use sphinx on stem
by Beck Chen 05 Jun '12

05 Jun '12

Hi Damian, I explored sphinx and tried it on stem these days, and it seemed pretty handy. I think a good way to produce nice documentation for stem is to create a page for each module manually, write an introduction by hand, and use autoclass / autofunction / autoexception in the autodoc extension to create API docs. automodule seems too general and does not work well with module's docstring in stem since it is not written in reST format, so I don't like it. What do you suggest? And how's your … [View More]

2 3

txtorcon, async Tor controller
by meejah 05 Jun '12

05 Jun '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erring on the side of "release early, release often" I have put my Twisted-based (asynchronous, Python) Tor control protocol implementation online: http://readthedocs.org/docs/txtorcon/en/latest/ https://github.com/meejah/txtorcon It is MIT licensed (to match Twisted). I would certainly not consider it "done", and I made it to learn more about Twisted and Python -- criticisms, comments appreciated. Currently it has the following features (… [View More]

3 6

GSoC Intro: Stegotorus
by vmon 04 Jun '12

04 Jun '12

Hello Tor-devers, It is a beautiful spring/summer day and this is vmon. I m going spend my summer with you guys. You might think that I m a bit off schedule with such a late GSoCc intro, but till 2 days ago I didn't know what I was going to do this summer for tor, so I couldn't write much before. I've been using tor for a long time. I don't remember exactly when was the first time I encountered Tor but I think it was somehow through JonDo. Being behind censor, you always desperately google … [View More]

4 3

TorStatus
by Felix Ker 04 Jun '12

04 Jun '12

I'm trying to use TorStatus and it took me almost 2 hours to set everything up and able to run tns_update.pl smoothly with no error. However, I am facing a problem that Google cannot help me. [0] starting... [0] mirror? [0] connecting to Tor [0] authenticating with Tor [0] starting descriptions *The TorStatus database was not updated properly. An error has occured. I will continue to try to update, however.* It says an error has occured but I am unable to find any error logs. Anyone? ___ … [View More]

3 5

[GSoC] Vidalia - Status Report
by Feroze Naina 02 Jun '12

02 Jun '12

I have completed the prototype for Torrc and I've tested it writing a plugin. So far value(), setValue(), TorrcPath() functions are confirmed working. I've still not been able to get clear() working and the execution simple stops. I'm not sure if there is an error in the plugin or the prototype without the debugger. I'm planning on integrating QScriptEngineDebugger to help writing and testing plugins. I didn't work in the first week during exams. My commits - https://github.com/feroze/vidalia/commits/hiddenservice

1 1

[GSoC] Pluggable Transports in Python Status Report
by Brandon Wiley 01 Jun '12

01 Jun '12

Deliverable #1 for this summer’s project is this: “A library for parsing pluggable transport configuration options This will be a python library that authors of SOCKS proxies can use to integrate their proxies with Tor.” A first pass at this is available from github and pypi: http://github.com/blanu/pyptlib http://pypi.python.org/pypi/pyptlib/0.1 I tried to follow the spec very closely in developing the API. Next steps for the library are testing, improvement documentation including pydoc … [View More]

1 0

Damian's Status Report - May 2012
by Damian Johnson 01 Jun '12

01 Jun '12

Hi all. As you may have noticed from the elevated traffic on this list a few of us are trying to do more development discussions in public. To that end I'm bucking tradition and sending my monthly status report here too. They've always been public... http://www.atagar.com/arm/log.php ... but since their initial emails have been on a closed list I doubt that most people knew that they existed. On that note, if anyone wants to hack on fun tor related python stuff then let me know! Stem is always … [View More]looking for new people that want to get involved. ======================================== Hi all. Spring is in the air, and with it many lovely things including the UW Street Fair, Folklife, and an iSec Open Forum. It also included a week of oncall but that doesn't count in the 'lovely things' column. On the upside though, this time it was pleasantly light (first time I've gone a whole week without being woken up by a pager at 3am!). As a GSoC admin I don't have much to report besides a blog posting at the start of the month [1]. However, as a mentor some neat things are in the works... * Ravi is adding SafeCookie support in stem [2]. I've code reviewed the first couple iterations and it's looking great. Given some tests and revising to fit with recent refactoring it should soon be ready to merge. After that he'll start working on the general controller. This last weekend I refactored how response classes are organized and implemented GETINFO as an example, so this will hopefully be an easy project for him to start hacking on. * Beck added descriptor validation to check that the signing key's hash matches its fingerprint [3]. This is the first part of descriptor integrity validation that Karsten suggested, however this project has gotten stuck so he's moving on to other stem tasks. * Investigated a couple issues brought up by Sathyanarayanan [4][5]. * Two Wesleyan students will start working on stem soon! [6] Needless to say helping these projects has occupies much of my time, and will take even more once the Wesleyan students get started. However, after years of trying in vain to attract developers to my projects I wouldn't have it any other way. :) Other stem tasks I finished this month includes... * ExtraInfo descriptor parsing. This took me a couple weeks since it contains so many attributes, but I'm glad it's finished. Now all that remains before we can port Onionoo are the consensus' network status entries. That's now at the top of my todo list for descriptor work, but I'm setting that list aside for now in favor of Sphinx and helping Ravi and Beck with controller work. * Improved the launch_tor() function, making the test instance easily configurable via a temporary torrc (similar to what Vidalia does) and adding integ tests. I also added a workaround so it'll work on Windows [7][8]. * Updated the stem development wiki [9] so it'll be easier for new volunteers to find tasks that interest them. * Discussed descriptor type annotations with Karsten and implemented stem's side of it [10]. We also discussed some changes to bridge descriptor sanatization which led to some minor stem changes too. Cheers! -Damian [1] https://blog.torproject.org/blog/gsoc-2012-projects [2] https://trac.torproject.org/5262 [3] https://trac.torproject.org/5810 [4] https://trac.torproject.org/5917 [5] https://trac.torproject.org/5918 [6] https://lists.torproject.org/pipermail/tor-dev/2012-May/003547.html [7] https://trac.torproject.org/5783 [8] https://trac.torproject.org/5493 [9] https://trac.torproject.org/projects/tor/wiki/doc/stem [10] https://trac.torproject.org/5651 [View Less]

1 0

Fwd: Re: Can we stop sanitizing nicknames in bridge descriptors?
by Karsten Loesing 29 May '12

29 May '12

Forwarding my original answer to Sebastian here. -------- Original Message -------- Subject: Re: [tor-dev] Can we stop sanitizing nicknames in bridge descriptors? Date: Mon, 21 May 2012 19:56:34 +0200 From: Karsten Loesing <karsten(a)torproject.org> To: Sebastian G. <bastik.tor> <bastik.tor(a)googlemail.com> Hi Sebastian, On 5/21/12 7:08 PM, Sebastian G. <bastik.tor> wrote: (Did you intend to send this mail only to me, not to tor-dev? Feel free to move the … [View More]discussion back to tor-dev if you want.) > Karsten Loesing, 21.05.2012 11:05: >>> >>> Here we go with the similarities of bridge and relay nicknames. >> >> Thanks for spending this much time on the analysis! > > I could have done far worse, but also a lot better in terms of time > spend on extracting the data that I wanted or at least considered that > they'd might be useful. > > Sometimes I'm just slow at things, e.g. writing this reply. > >> Here's what I did with your findings.txt: >> >> - extract unique fingerprint pairs of relays and bridges that you found >> as having similar nicknames, >> >> - look through descriptor archives to see if relay and bridge were >> running in the same /24 at any time in May 2008, and >> >> - determine the absolute and relative number of bridges in a given >> network status that could have been located via nickname similarity. >> >> Results are that 24 of your 81 guesses (30%) were correct in the sense >> that a bridge was at least once running in the same /24 as the relay >> with similar nickname. At any time in May 2008, you'd have located >> between 1 and 6 bridges (2.5% to 18%) with 3 bridges (10%) in the mean >> via nickname similarity. > > Not too bad. I agree. :) >> I think it's acceptable to publish more recent bridge descriptors with >> nicknames in a week from now. Results may look quite different with >> 1000 bridges instead of 30. > > May 2008 was the first month with bridges. I expected lot's of relay > operators that tested a bridge with the same name. Things may have > changed over time. I assume that further comparisons won't have such a > "high" hit ratio. That would be my guess, too. In May 2008, only a few early adopters were running bridges, and most of those probably ran relays at the same time, too. Plus, they were enthusiastic and put some energy in finding cool nicknames. It might be that this has changed since then. To be honest, I didn't look at 2012 tarballs yet. >> Again, thanks for running this analysis! Maybe you're interested in >> automating your comparison and re-running it for a 2012 tarball? > > My claim was you got the data, so you can check. (Not with May 2008) > > To be honest, my first impression was that I wouldn't do anything useful > and did not intend to do that. I guessed it wouldn't turn out that it > doesn't hurt since at least 2011, so I wouldn't find anything good. > > Then you asked and I agreed, but already thought "I couldn't keep my > mouth shut!". I mean I replied to this topic. I surely could have said > no there. I didn't. > > After and while I was doing what I did. I would have said no to the > question if I'm going to do this again. That's valid for up to Sunday > night. Today I'm agreeing again. > > That's a pretty long way to say: Yes! Hah, great! :) I'm going to make the 2012 tarballs available next Wednesday (May 30), assuming that my poor Linux box doesn't run out of $resource. I'll let you know. > Thank you,it's an 2012 tarball. The number of bridges is scary. > > I'm going to upload some files somewhere and explain what I did. Step by > step (somewhat around that). So anyone can check and reproduce what I > did. It would be nice to hear feedback and ways to improve the way I did > what I did. > > Maybe you can tell me if the findings.txt was alright. Yes, the file format was fine. > Unless one objects or you disagree I'm going to upload the files I > created and explain how and maybe I can say even why. No objections at all. Open discussion is good. > I created a Blog, just because I wanted it some when in the past, but > found it silly. That's the channel I planed to use. Maybe it's OK to put > it on a Tor-List as well, but maybe it's considered as noise. I wonder if the Tor wiki would be a better place to collect ideas for reversing the bridge descriptor sanitizing process. Feel free to grab a new page in doc/ and start describing what you did. Best, Karsten [View Less]

2 4

[GSoC] Update - Safe cookie support in Stem
by Ravi Chandra Padmala 28 May '12

28 May '12

Hello I'm reporting my progress over the last week. I have been working on implementing support for the safe cookie authentication method for Stem[1]. It is in a usable state[2] right now, but, it isn't fully tested. In the process, Stem also helped uncover a bug in the AUTHCHALLENGE error responses[3]. Now, I'll be writing the tests for the safe cookie implementation and getting it merged. Next, I'll begin work on the general controller class. Damien has already implemented an the GETINFO … [View More]

1 0

Sanitized bridge descriptor format 1.0
by Karsten Loesing 24 May '12

24 May '12

Hi Damian, I plan to make a few changes to the bridge descriptor sanitizer to implement changes discussed on this list and in various Trac tickets. The result will be format version 1.0. Here's what will change compared to the current (unversioned) format. Can you take a look whether stem would be happy with these descriptors and if there are other tweaks I should do to make it even happier? - Bridge network statuses contain a "published" line containing the publication timestamp, so that … [View More]

2 5

GSoC Introduction - Pluggable Transports in Python
by Brandon Wiley 22 May '12

22 May '12

Hello fellow Tor developers! Some information about me: *I worked for EFF/Tor Project last year for **GSoC 2011, my project **was a blocking-resistant transport evaluation framework: https://gitweb.torproject.org/user/blanu/blocking-test.git* I am also the author of a pluggable transport written in python: https://github.com/blanu/Dust/tree/master/py/dust/services/socks2 I've been working on censorship resistance technology since 2001. Here are some of my projects: http://blanu.net/Dust-… [View More]FOCI.pdf http://blanu.net/BayesianClassification.pdf http://blanu.net/Arcadia.pdf http://blanu.net/Freenet2001.pdf Some information about the project: The overall goal of the project is to make it easy for pluggable transports to be written in python. There has been a lot of interest in doing pluggable transports in python, but currently they are all written from scratch. For C transports, obfsproxy can be used to do a lot of the heavy lifting, making it relatively easy to write a new C-based transport. I've heard there is also a port of obfsproxy to C++. A the author of a python transport, I am of course an advocate of writing transports in python. Fortunately, so are some other Tor folks, so soon it will be easy to write python transports! The deliverables for this project are as follows: *A library for parsing pluggable transport configuration options* This will be a python library that authors of SOCKS proxies can use to integrate their proxies with Tor. *A framework (both server and client-side) for writing pluggable transports in python* The framework will provide a SOCKS proxy server already integrated with the pluggable transport library. All the protocol author will need to do is provide the obfuscation and de-obfuscation functions and a main function to do command line parsing and call the framework. *A python implementation of the obfsproxy command line tool* This will be a command line program using the framework that will accept the same command line options as the existing obfsproxy tool. It will support the selection of an obfuscation function, although not all of the protocols currently supported by obfsproxy will initially be available in python. *A python implementation of the obfs2 protocol implemented as an obfsproxy module* The obfs2 protocol will be implemented as a plugin for the framework and made available to the command line tool. *Conversion of Dust to an obfsproxy module* The Dust protocol will be implemented as a plugin for the framework and made available to the command line tool. *py2exe packaging for obfsproxy* The command line tool will be packaged into a standalone executable for Windows. Optional deliverables if there is sufficient time: obfsproxy modules for other protocols, experiment with other packaging systems Current status: I'm working on a spec of the API for the option parsing library. It should be available soon. [View Less]

2 1

[GSoC] [APAF] Report of 17-21 May hackathon; current status of APAF.
by Michele Orrù 21 May '12

21 May '12

I'm writing this mail as report for the last four days during which, thanks to the supervision of both naif and hellais, I managed to develop the very first basic structure of the APAF project. One nice thing that came out during this weekend was the collaboration and improvement of other python projects, txtorcon[0] and py2app[1]. Especially, I hope to continue improving txtorcon, which will be the most strict dependency for the apaf project. At the end of this hackaton, I reached a state in … [View More]

1 0

unscribe
by torbridges.security 21 May '12

21 May '12

unscribe

1 0