- tor-dev - lists.torproject.org

Re: [tor-dev] [tor-assistants] Python metrics-lib
by Karsten Loesing 05 May '12

05 May '12

[Moving this thread to tor-dev as suggested by Damian in separate mail.] Hi Damian, hi Beck, On 5/4/12 6:59 PM, Damian Johnson wrote: > Hi Beck. > >> I noticed that stem has not been updated during the last ten days > > Yup, I've been busy for a while with a new arm release [1] and a > variety of other chores. Ravi is currently working on safe cookie > support and I'll be getting back into stem development this weekend. > >> it's a good time to start doing some substantial work > > Great! > >> So for me, a reasonable next step is to build some subclass on top of the base Descriptor class. What do you think? > > Sounds good. What descriptor type would you like to tackle first? > Karsten, do you have any suggestions? Ravi plans to do network status > entries and microdescriptors so I'd suggest something besides those. There are quite a few options. How about extending stem to implement #2768? There's already Java code for verifying server descriptors and consensuses in metrics-tasks.git [0]. On stem's side this requires parsing the crypto parts of server descriptors, consensuses, and certificates. If the network statuses aren't there yet, starting with server descriptors should be fine. And once there's verification code for server descriptors and consensuses, there are more things to verify in Tor's various descriptors. Another option would be to write the parsing code for extra-info descriptors including all the stats. Once we have consensuses, server descriptors, and extra-info descriptors in stem, we can start writing a Python version of Onionoo [1], the service that provides the data for Atlas [2]. Let me know if you need more options or more input on these. Thanks, Karsten [0] https://gitweb.torproject.org/metrics-tasks.git/tree/HEAD:/task-2768 [1] https://www.torproject.org/projects/onionoo.html.en [2] https://atlas.torproject.org/ > Also, since you're interested in this area I'd suggest giving this a read... > https://trac.torproject.org/projects/tor/ticket/5651 > > There's nothing that needs to be done for it on our end at the moment > - just related to the stem/metrics-lib work. > > Cheers! -Damian > > [1] https://blog.torproject.org/blog/arm-release-145 > > On Fri, May 4, 2012 at 9:32 AM, Beck Chen <csybeck(a)gmail.com> wrote: >> Hi Damian, >> >> Greetings! I've read through the metrics-lib and stem.descriptor code and >> skimmed the directory server specs since you sent me the discussion thread >> between you and Karsten. I noticed that stem has not been updated during the >> last ten days, and since I've finished my semester and gone back to China, >> it's a good time to start doing some substantial work. >> >> In stem.descriptor, we already have counterparts for Descriptor.java, >> DescriptorReader.java, and ServerDescriptor.java now, and as you mentioned, >> they pretty much behave in the same way. So for me, a reasonable next step >> is to build some subclass on top of the base Descriptor class. What do you >> think? I believe you have discussed this with Karsten, so it will be helpful >> if you can forward me some of your discussions. >> >> Beck

2 1

[GSoC] Greetings!
by Ravi Chandra Padmala 28 Apr '12

28 Apr '12

Hello everyone. I'm Ravi Chandra Padmala (aka neena). I'm an undergraduate student at GITAM University in Visakhapatnam, India. I've been a user of open source software for 6 years now. My go-to programming language is usually python. I have tinkered with a few other languages, and I try my best to be programming language agnostic, I will be working on Stem this summer (as a part of the Google Summer of Code program). Damian (atagar) is my primary mentor. Among other things, I'll be implementing the general controller class for Stem. If anyone is interested in exactly what I'm going to be working on, do take a look at my proposal which is available here[1]. If anyone needs to contact me, this is my primary email. I'm 'neena' on IRC (irc.oftc.net) I'm geographically located in GMT+5:30. (Though, my body clock is in GMT-1). -- Cheers, neena [1] https://www.torproject.org/about/gsocProposal/gsoc12-proposal-stemImproveme….

1 0

New from GSoC
by 九零后 27 Apr '12

27 Apr '12

Hi, I come here from GSoc and want to join project Obfsproxy. But I can't find the contributors' mail , where can I get it?

2 1

[Patch] test_util.c with MSVC
by Gisle Vanem 26 Apr '12

26 Apr '12

The src/test/test_util.c doesn't compile with MSVC (CL ver. 16.00.30319.01). It doesn't like the "#ifdef 0" construct, but the whole chunk should be enabled with some modifications IMHO. 'path_is_relative()' doesn't handle the "http:\\dir" case though. Why should it? Besides 'expand_filename()' isn't for Windows. I suggest this patch: --- Git-latest\src\test\test_util.c Fri Apr 06 22:45:14 2012 +++ src\test\test_util.c Thu Apr 26 08:59:18 2012 @@ -1526,10 +1526,6 @@ /* Windows */ #ifdef MS_WINDOWS - /* I don't have Windows so I can't test this, hence the "#ifdef - 0". These are tests that look useful, so please try to get them - running and uncomment if it all works as it should */ -#ifdef 0 test_eq(1, path_is_relative("dir")); test_eq(1, path_is_relative("dir\\")); test_eq(1, path_is_relative("dir\\a:")); @@ -1538,8 +1534,7 @@ test_eq(0, path_is_relative("\\dir")); test_eq(0, path_is_relative("a:\\dir")); test_eq(0, path_is_relative("z:\\dir")); - test_eq(0, path_is_relative("http:\\dir")); -#endif + test_eq(1, path_is_relative("http:\\dir")); /* path_is_relative() doesn't test for such */ #endif done: @@ -2887,7 +2882,9 @@ UTIL_LEGACY(config_line_quotes), UTIL_LEGACY(config_line_comment_character), UTIL_LEGACY(config_line_escaped_content), +#ifndef MS_WINDOWS UTIL_LEGACY(expand_filename), +#endif UTIL_LEGACY(strmisc), UTIL_LEGACY(pow2), UTIL_LEGACY(gzip), With the above, test/test.exe now says: util/path_is_relative: OK --gv

3 2

[GSoC] Introduction - Vidalia
by Feroze Naina 26 Apr '12

26 Apr '12

Hello, I'm Feroze and I will be working on the hidden service configuration and bandwidth scheduling plugins for Vidalia. I'm specially excited about the bandwidth scheduling plugin as I've felt the need for this. Users would like to specify different bandwidth allocation for Tor relay at different times. Currently, you have to setup a cron job and manually create a script which is tedious. I will be creating a simple interface to specify hour-wise bandwidth for every day of the week. My proposal outlines this in detail - http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/feroze/6… I'll be on #vidalia and #tor-dev with the nickname feroze.

1 0

[GSoC] Tails-server - Introduction
by jvoisin 25 Apr '12

25 Apr '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I am jvoisin, the student who will work on tails-server[1] during this year's GSoC; my mentors will be intrigeri and anonym. I already worked for Tor last year, on the "Metadata Anonymisation Toolkit" project[2]; and I hope that I'll do as good (and even better) than last year ! You can check my proposal[3] if you are curious/interested about what I'm planning to do this Summer. I'm hanging on #tor-dev with the nick jvoisin. Have a nice day, - - jvoisin 1. https://tails.boum.org/todo/server_edition/ 2. https://mat.boum.org/ 3. https://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/jvoisin… -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPl+vOAAoJEJdo/TzEiBXynroP/jgiFrf3/NgEyZXSqvlAENw9 cLrUvDl2auYq78l0cuwJXxS3qb4ypow8VfqLHhFEn9I+d3ei7l1L5ozO6QkLcjYy RISnWcN5HFkr5VKbU3LcSWXe50WqHh2/8SvzZxraMLpLpxxrOSWT9YnUtRu/m+LR aX5X10HXlsmTqrNEoJgUfzgePSwYUDltAHPrzI7NelznS+CyCukRpuJ/nJd3fkSR u/xlxoZR5aX3dIHMwupUISG0B59aYYbp1XUw1rYz+/XXMxLzcKblP+UqRk3ayuMg a2LVY1pA32wrS6Bev6rwf+7xYdbVYDpLgWkSfZIenP3q2ynv14iLkIkruQK73d4V ibj9DydcRBOhzdOm36xqoV1ddhI6upJqxPC53dwInCYQLuZUf8mu0tvNI/yivaGA MkvAFabPLpaqk8KNDPSoBFVgigsjJgXfHfkM3MUd8zLrHQf//Q9wYlr1MMZNNyG6 ajhZqRdFKiEUb6Mxgk3sVcIvZCTC37Kkd4RGWBcm8VMLZz/9+7346sgcx/E4yB5o GgU0qthsWB9Gpb7+VckedQFwQ/G+Ffjd7RIV3VJuTU6+QH7NPy1wmc30bVBE0wCY keLmWAOKVbDe5QmpZokx/j+Nx8gAah61Atq3BKFmshwI980BpCEC0KemGtEH8+oR mywN3qE7fF18micBUVWW =We9H -----END PGP SIGNATURE-----

1 0

Greetings && The APAF project
by Michele Orrù 24 Apr '12

24 Apr '12

Hello. I'm wrtiting this email to introduce myself to the tor community. I'm new to tor, I've started to discover its community with the GlobaLeaks project; and now, for the Google Summer of Code, I will be involved in the APAF project. So probably all these days I will hang around your irc channel and this mailing list, getting known to some of the core developers. The APAF project, as described by Arturo in https://lists.torproject.org/pipermail/tor-dev/2012-March/003416.html , aims to be a static file server written in python, on the same development idea behind the tor browser bundle: being a simple and portable executable for non-technical user. So, the core idea is to create a python standalone .exe / .app so that anybody can easily set up a tor hidden service and configure it (via web browser or gui, to be defined); hoping that this will spread the use of hidden services, which AFAIK, nowdays aren't so much used. The most powerful concept behind this in my opinion is that, by design, the APAF should be as modular as possible, so that any other python application developer will be able to build its own software in such a way that it runs as a Tor Hidden Service. "Most powerful" becouse learning and collaboration shall be behind the opensouce idea, which is what I hope to work for. Deadlines for the project are described in https://pad.riseup.net/p/APAF-timeline Starting today, I am going to outline the design of the APAF - which libraries it is going to use, mockups, how to be configured, and so on. Since I will probably discuss all these choices with my mentor Arturo on the irc channel #tor-dev, any advice is welcome :) Regards, -- ù

1 0

Alternatives to Tor Exit Enclaves
by Arturo Filastò 19 Apr '12

19 Apr '12

The purpose of Exit Enclaves was to allow people running a website to make Tor users access it without ever leaving the Tor network. This leads to the clients having end-to-end encryption with the target destination. Even in previous version this had some issues, one of which was the fact that at the first connection the user would not be accessing the destination over a Tor circuit if the destination was provided in a hostname format (and not IP). The current stable version of Tor (0.2.2.x) still supports Exit enclaves. The new versions of Tor (> 0.2.3.x) use a new descriptor format (microdescriptors) allow relays to specify an Exit Enclave policy, but clients will not use it, therefore voiding the purpose of exit enclaving. I believe there is the need for something similar to Tor Exit Enclaving and the closest thing I see fit these requirements are Tor Encrypted Services (https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-en…) Encrypted Services (EC), are basically regular Tor Hidden Services, that do not provide anonymity for the server and gain a better performance because of this (they have a one-hop circuit to the RV and IP). The problem with making Encrypted services work to replace Exit Enclaves is that the client needs to have a way to understand that their destination is running also as an Encrypted Service. In this very high level overview I don't go into very much detail of how this system will actually work, but I hope it will prompt some discussion on the matter. I think this can be achieved mainly in 3 ways. 1) The client already knows all of the EC's 2) The client looks up if a destination is an EC when trying to connect to it 3) The final hop looks up if the destination is an EC These all have some drawbacks: In 1) the client needs to download the full list of EC's, therefore if the number of EC's get's very large it will take clients much more to bootstrap and they will need to store more data. The good thing of this though is that the speed of connections would be as fast as they are at the moment as it does not require any extra connections. In 2) the clients needs to complete an extra round-trip for every connection. I don't think this is a valid solution as it would degrade the quality of connections for every user. In 3) the final hop would do along side a normal A lookup for hostnames a CNAME lookup ( or another special field). If it finds that such a lookup returns a .onion address instead of returning a RELAY_CONNECTED cell it will return a ENCRYPTED_SERVICE cell containing the .onion address of the target ES. The client will then cache this address and connect to it. This approach adds a little bit of overhead (since two DNS lookups need to be made), but it is still faster than 2). It suffers from the issue of the exit node could spoof the .onion address and redirect the user to a malicious .onion address. This is quite a tough problem that I am still unsure how it could be solved. If we have support for DNSSec this issue could be mitigated. I would love some feedback on this topic. - Art.

4 6

brdgrd: Protecting bridges from the GFC
by Philipp Winter 15 Apr '12

15 Apr '12

Hi, I've been working on a small tool whose purpose is to protect bridges from the Chinese firewall. The tool runs independently of Tor and analyzes/rewrites SYNs and SYN/ACKs which it gets with the help of libnetfilter_queue. It is quick and easy to set up and can be run by bridge operators. Basically, the tool achieves two things: - Evading the Chinese DPI engine by rewriting the TCP window size during the TCP handshake. This leads to a fragmented cipher list which does not seem to be recognized by the GFC. - Blocking scanners with two dirty hacks. I did not have a lot of time to test it yet but I've found the window size rewriting to be particularly effective (yet ugly). It worked with Windows {XP, 7} and recent Linux boxes. The scanner blocking strategies are not that effective since they imply many false positives, i.e., legitimate users being locked out. Before showing this to a broader audience, I need some people looking at the code, though. The code, just 600 lines of C, is available at: https://github.com/NullHypothesis/brdgrd/ Cheers, Philipp

1 1

WebSocket pluggable transport
by David Fifield 15 Apr '12

15 Apr '12

Here is a draft of a proposal for a pluggable transport using the WebSocket protocol. In short, WebSocket is a socket-like feature accessible to JavaScript in newer web browsers. Here are some links about it: https://tools.ietf.org/html/rfc6455 http://dev.w3.org/html5/websockets/ https://developer.mozilla.org/en/WebSockets WebSocket is the transport used by flash proxies (which now use JavaScript instead of Flash). This pluggable transport is a necessary part of the flash proxy system as it stands, because something needs stand between a Tor client and a web browser proxy, and again between the proxy and a Tor relay. This proposal is mainly describing what is already implemented in https://gitweb.torproject.org/flashproxy.git The program connector.py is the client transport plugin, and for the server transport plugin I'm using a program called websockify. (websockify isn't completely satisfactory though, and replacing it is ticket #5575.) What's implemented works well enough that I have been using IRC over Tor over a WebSocket transport for about a week. I want to emphasize that this proposal is not the entirety of the flash proxy architecture, but only a part of it. I'm posting it here because 1) I want your help in getting it right, and 2) it may be useful beyond just flash proxies. Anyone interested in reading the proposal, I'd like to call your attention to a few points for comment. One is that there are different, partially incompatible, version of the WebSocket protocol. I have made the most recent version (RFC 6455) a MUST and any earlier versions a MAY. However it may be that in a little while browser support will be such that there is no reason to support old versions. The other is the base64 subprotocol used to send binary data over a text-only channel. WebSocket has a fully binary messages, but they are not supported in Firefox 10. This may be another thing that is changing rapidly enough to drop, as Firefox 11 and Chrome 16 do support binary messages. David Fifield

1 0