- tor-dev - lists.torproject.org

Design for an exit relay scanner: feedback appreciated
by Philipp Winter 03 Dec '13

03 Dec '13

I am working on a Python-based exit relay scanner which should detect malicious and misbehaving exits. The design should have a reasonable balance between being fast/parallel and stressing the network as little as possible. I came up with the following three steps: 1. Spawn a "parent" Tor process to get an up-to-date consensus. 2.1 For every selected exit relay, spawn a lightweight Tor process. 2.2 The consensus is copied from the "parent" process to the lightweight process' data directory. That way, the consensus has to be downloaded only once. 2.3 Every lightweight Tor process has the following configuration: --- SOCKSPort auto ControlPort 0 __DisablePredictedCircuits 1 UseEntryGuards 0 FetchServerDescriptors 0 DataDirectory <data_directory> ExitNodes <exit_relay> --- Entry guards are not used to distribute the load. Predicted circuits are disabled to prevent expensive creation of circuits which would not be used anyway. In addition, I am considering adding "EntryNodes" or "Bridge" to concentrate the first hop's load on machines under my control. 3. torsocks is then used to establish decoy connections over the respective exit relay. After that, the process is terminated. Any thoughts on how to further improve the design or ideas for a better one? Cheers, Philipp

7 14

Orbot+Orchid redesign
by Bruce Leidl 02 Dec '13

02 Dec '13

> This makes me wonder: Would it be helpful to start compiling a big > list of things which could go wrong with a Tor implementation without > making it obviously broken? I think a checklist like that might help > people working on compatible implementations to have some idea what to > look for once you have something that interoperates. Would you have > found that useful? Would you find that useful now? Yes, for sure. I would have found that very useful because the delta between a working implementation and a secure implementation is quite large and a checklist would allow me to go down the list and at least *know* that I'm missing things. Some of these details may even be underspecified and there would be no easy way for me to find out about them. --brl

1 0

Orbot+Orchid redesign
by Bruce Leidl 02 Dec '13

02 Dec '13

>> Any objections to this approach? Is Orchid ready for this? > > It seems like a good architecture to target. I'm not sure that the > current Orchid codebase has gotten as much review yet as it would need > before I'd be comfortable making it the default option, but an > experimental build could be a fine idea. > > (My two cents' worth; two cents not refundable) Hi, Orchid (previously called JTor) author here, I agree with Nick to be cautious about rushing out and replacing Tor with Orchid for really important projects. I believe that it works well and that it is implemented correctly and securely, but you may want to collect more opinions than just mine about that. Although Orchid is advertised as working on Android, the amount of testing on Android has been very light so far. So please start using Orchid experimentally to discover bugs and other inadequacies, but for projects that can get away with using C Tor that's probably a better plan for now. To help you decide if Orchid is appropriate for use here's a list of important things which have not (yet) been implemented: * Path bias defense * Adaptive circuit build times (also, path bias depends on this?) * Stream isolation * Optimistic data * Control protocol * Publication of hidden services (I don't understand the description of Adaptive CBT in the spec at all, so I would either need to blindly copy the implemenation from Tor (i.e circuitstats.c) or need help from the original author.) --brl

2 1

OnionMail english help
by Liste 02 Dec '13

02 Dec '13

OnionMail english paper: http://onionmail.info/paper.html I am building some new function for the next version: * SysOp operations via mail. * Server Manifest 2.0. * Remote Keyblock. * GPG native support. * Applications transport.

1 0

Re: [tor-dev] TOR peer-to-peer network
by Aravindan B 01 Dec '13

01 Dec '13

> > Hi all, > > I am stuck at one point and not able to proceed. I want to establish a > peer-to-peer TOR network using Stem. I am trying to simulate TOR in VANET. > I am using CORE emulator (VANET) and Stem tor for the same as both supports > python scripts. > > As you can see in the attached topology I am wanted to use 4 nodes with > 10.0.0.21 as client, > 10.0.0.22 - entry > 10.0.023 - middle node > 10.0.0.24 - exit node > > I am trying to setup a peer-to-peer tor network with these above nodes. > I am using TOR bridges for the entry and middle nodes. This is working fine > if I run it outside core whereas when I try to run these bridges inside > core emulator with those node IP:ports, its failing and TOR circuit is > timing out. Is there anything I need to run on these nodes like a server or > something (if yes, need a code for that) to respond to the connecting tor > client? > > When i use the bridges which i got from the internet, it works. whereas > when i try to use my own IPs its not working. Please let me know how to > proceed on this as i am stuck here for a long time. Thanks in advance. > > Thanks and Regards > Aravindan > >

2 1

Orbot+Orchid redesign
by Nathan Freitas 01 Dec '13

01 Dec '13

Now that Orchid is released at a v1 stage, I have been thinking about having Orbot use it by default, and then offering ARM and x86 binaries as add-on enhancements. This would make the core Tor on Android experience more lightweight for client only use. If people want to run relays, need a higher performance option or want the "real" Tor, they can get the Orbot native APK add-on for their architecture. Any objections to this approach? Is Orchid ready for this?

2 1

Dynamic Networks in Chutney
by Christopher Baines 30 Nov '13

30 Nov '13

I am attempting to use Chutney to test some hidden service related functionality in Tor. Specifically distributed hidden services involving more than one node. Furthermore, to extensively test aspects of this, the network needs to change. At the moment, I have just looked at nodes coming up and down, but this could probably be extended also. Currently I believe the support for this functionality is limited to a patch (very functional, I have been using it successfully) that allows nodes to start after a delay [1]. While this does work, this could make any tests that use delays respond differently depending on what system they are ran. The best solution to this that I can see is using some event based system, such that chutney (using an existing Tor controller) connects to the nodes as necessary, to check their state, and trigger any events as necessary. A few high level examples that I would like to use: - when node 010h has uploaded a descriptor for service <service>, start node 011h - when any of nodes (000a, 001a, 002a) have a service descriptor for <service>, start node 011h Do others using/developing chutney think this would be a useful addition, and is anyone already working on doing this or similar? 1: https://trac.torproject.org/projects/tor/ticket/10155

2 1

OnionMail: First public server + 2 Hidden services.
by Liste 28 Nov '13

28 Nov '13

OnionMail Ver. 0.1.3B Is out! OnionMail is a SMTP/POP3 Mail hidden service with tor->mail (exit), mail->tor (enter). Now an exit/enter node is onionmail.info How to get an OnionMail box: http://onionmail.info/reqmail.html We suggest the `ridot` server. How to install OnionMail http://www.youtube.com/watch?v=FcM01lT9b3A http://onionmail.info

1 0

Tor Ecosystem Presentation
by Damian Johnson 28 Nov '13

28 Nov '13

Hi all. A little over a week ago I gave a presentation at Seattle's TA3M at Ada's Books to give an overview of the projects within the Tor ecosystem. This is a revised version of a similar presentation Roger and Jake gave at 29c3... Presentation: https://archive.org/download/t3am-seattle-nov2013/damian_johnson.mp4 Slides: https://www.atagar.com/transfer/tor_ecosystem/ I'm really startled about how high pitched my voice turned out. Strange I've never heard myself recorded and played back before. That aside, the presentation turned out pretty well. Many thanks to Lee and Chirs (TA3M's organizers) and Mr. Caggiano who recorded the presentation. Cheers! -Damian

3 2

Trac upgraded to 1.0
by Erinn Clark 28 Nov '13

28 Nov '13

Hi everyone! Weasel and I have upgraded https://trac.torproject.org/projects/tor to version 1.0 of Trac. I've tried to make sure that all functionality is the same (or improved), but if you see anything missing or broken, please let me know! Thanks, Erinn

1 0