- tor-dev - lists.torproject.org

Email Bridge Distributor Interactive Commands
by Matthew Finkel 30 Jul '14

30 Jul '14

Hi everyone, A short time ago BridgeDB learned how to accept some more commands via email[0]. Below is an example of the current help/overview autoresponse email[1] that users receive (in English, we do have translations). These commands may not be optimal, so we'd love to be given feedback on this so we can improve it. Currently, with the recent changes, we require all commands begin with 'get' and then we check which keyword follows it ('bridges', 'transport', 'help', 'key', etc). This certainly makes the parsing logic easy (and I am a fan of KISS), but it may be true that this is a bit too strict and decreases its usability. Would it be better if we were more lax? For example, instead of requiring: 'get transport <TYPE>' we change this to: '[[get] transport] <TYPE>' Therefore the 'get' and 'transport' keywords are optional (and 'get' is only used if you use 'transport'). <TYPE> is the pluggable tranport method name you want the bridges to support. I think this simplifies the user interaction but I don't know if it's significant and to what extent most users care about this. It should be mentioned that prior to the recent changes, sending a blank email to bridges(a)bridges.torproject.org was equivilent to sending an email that contained 'get bridges' because we didn't actually check for 'get bridges' at all, we do this now, though. So, the questions I am posing to those in the community who has an opinion about this: What do you think? What problems do you currently have with this? How can this be improved? Thanks! Matt [0] https://trac.torproject.org/projects/tor/ticket/7550 [1] > Hey, <you>! Welcome to BridgeDB! > > > > COMMANDs: (combine COMMANDs to specify multiple options simultaneously) > get bridges Request vanilla bridges. > get transport [TYPE] Request a Pluggable Transport by TYPE. > get help Displays this message. > get key Get a copy of BridgeDB's public GnuPG key. > get ipv6 Request IPv6 bridges. > > Currently supported transport TYPEs: > obfs2 > obfs3 > scramblesuit > > > BridgeDB can provide bridges with several types of Pluggable Transports[0], > which can help obfuscate your connections to the Tor Network, making it more > difficult for anyone watching your internet traffic to determine that you are > using Tor. > > Some bridges with IPv6 addresses are also available, though some Pluggable > Transports aren't IPv6 compatible. > > Additionally, BridgeDB has plenty of plain-ol'-vanilla bridges - without any > Pluggable Transports - which maybe doesn't sound as cool, but they can still > help to circumvent internet censorship in many cases. > > [0]: https://www.torproject.org/docs/pluggable-transports.html > > -- > <3 BridgeDB > ______________________________________________________________________ > Public Keys: https://bridges.torproject.org/keys > This email was generated with rainbows, unicorns, and sparkles > for your(a)email.com on Sunday, 20 July, 2014 at 16:59:19. >

12 34

Working on a Globe Fork
by William Papper 29 Jul '14

29 Jul '14

Hi all, I'm a freelance web designer and developer, and I'm working on a fork of Globe after seeing the recent blog post <https://blog.torproject.org/blog/looking-front-end-web-developers-network-s…> on the Tor Project's website. Since none of the other forks have any changes or are actively maintained, I created a fork on GitHub here <https://github.com/wpapper/globe> . I'm going to start by improving the responsive aspects of the design, and also clean up some unclear design decisions (e.g. Changing to something more descriptive than "keyword" for the search box and removing some redundant UI elements). I'll be making GitHub issues for the changes that need to be made. Anyone else can add any issues they see there. If you'd like to help contribute, just take on an issue and submit a pull request. Of course, let me know if you have any comments or suggestions. Sincerely, Will Papper

1 0

orbot: get its ports from another app
by CJ 29 Jul '14

29 Jul '14

Hello, I'm currently developping orwall, a UI over iptables allowing to block all IP traffic and forcing selected apps through Orbot (while blocking the others), among other things. I'm wondering if there's a way to ask Orbot, if installed, its SOCKS and TransPort configuration. I think NetCipher lib may do it, but I'm not that sure. Thanks in advance for your answer/help :). Cheers, C.

2 2

GSoc Stegotorus status update
by Noah Rahman 29 Jul '14

29 Jul '14

Sorry for the delay, I have been travelling for the past week and a half and was at HOPE. I have finished debugging the swf steg, and am hunting down the last bugs in the pdf steg. SRI advised me that they are still working on their JavaScript transcoding library they wish to plug into the SWF and JS stegs, so I will move the JS steg and JSON stegs over but at the unti tests for JSON first. By the time of the PT meeing on August 1st I intend: to have JS, SWF and PDF debugged with unit tests finish testing the handshake code and make it robust to packets arriving out of order (discussed ideas for this in person with vmon) be ready to start debugging the transparent proxy start sketching out how to incorporate the JSON steg and the SRI jel library (if they get it finished in the next two weeks) Best Noah

1 0

Please merge these anti-fingerprinting bugfixes
by faether 28 Jul '14

28 Jul '14

Can a TBB developer please push these very simple but important anti- fingerprinting prefs through: pref("full-screen-api.enabled", false); pref("browser.link.open_newwindow.restriction", 0); pref("dom.disable_window_move_resize", true); Fixing: https://trac.torproject.org/projects/tor/ticket/12609 (two weeks old) https://trac.torproject.org/projects/tor/ticket/9881 (ten months old) I've written a proposal to treat fingerprinting related bugfixes like other security bugfixes with regards to urgency and release management: https://trac.torproject.org/projects/tor/ticket/12715

2 1

Re: [tor-dev] Chutney couldn't start Tor instances
by Jesse Victors 27 Jul '14

27 Jul '14

Thanks Sukhbir, This was exactly it. I took me a few times, but I got it in the end. To make Chutney work: 1) Comment out the "TestingClientDownloadSchedule" line in torrc_templates/client.tmpl and in torrc_templates/client.tmpl 2) Comment out the "TestingV3AuthVotingStartOffset" line in torrc_templates/authority.tmpl 3) In torrc_templates/authority.tmpl, change the value of "TestingV3AuthInitialVoteDelay" from 2 to 20 4) In the same file, change the value of "TestingV3AuthInitialDistDelay" from 2 to 20. These are the lowest these values can go. 5) $ ./chutney configure networks/basic 6) $ ./chutney start networks/basic 7) $ ./chutney status networks/basic As you pointed out, removing line 469 of lib/chutney/TorNet.py (removing the --quiet option at launch) does give some great diagnostic information. 10/10 nodes now running, thanks again for the help. Hopefully the Chutney devs see this! Relevant: https://xkcd.com/196/ -- Jesse V. On 07/27/2014 04:00 AM, tor-dev-request(a)lists.torproject.org wrote: > Date: Sat, 26 Jul 2014 18:51:44 -0400 > From: Sukhbir Singh <sukhbir.in(a)gmail.com> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Chutney couldn't start Tor instances > Message-ID: > <CADtjFvXs=Zfvus75iSs6oUZ1tXmwayVG+3HZv8n4OVR8-5+5+w(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi, > >> No log files are generated in <path>/net/nodes/000a, so I don't know what >> happened. I don't see any conflicts with ports on localhost as far as I can >> see. >> Tor version 0.2.4.22 and Python 2.7.5+ are installed. Any ideas? > I find it helpful to remove the "--quiet" switch from > lib/chutney/TorNet.py (line 469) so that I can actually see why Tor > failed to start. That is the right place to start looking. > > In your case, it is probably TestingClientDownloadSchedule or > TestingServerDownloadSchedule that is causing the issue since I > remember something with one of the versions in 0.2.4 (not exactly sure > which). Try removing these lines from torrc_templates/client.tmpl, > torrc_template/relay.tmpl and then reconfigure the network and then > start it. It is either this, or DirServer/DirAuthority but the verbose > output will tell you the exact problem (look for "err"). > > I have found these issues to be common when using an earlier version > because of mismatch between the templates Chuntey is configured to use > (recent versions of Tor) versus earlier versions with different > options. But the fix is easy -- just update the template and > reconfigure the network. >

1 0

[404] :-( Retrieving Hidden Service Public-Key ...
by Achref Akremi 27 Jul '14

27 Jul '14

onion adress: 3g2upl4pq6kufc4m.onion date: 18 Jul 2014 22:27:20 GMT 1st: compute the v2 descriptor id: > with replicas 0: efa0506e1e5d3f193bf6509e1f4709e6e2322436 > with replicas 1: efa0506e1e5d3f193bf6509e1f4709e6e2322436 2nd: find responsible HSdir's: > efa0506e1e5d3f193bf6509e1f4709e6e2322436 > pmocek > marcuse1 > riptide > fc2c757e88910b3d72594706c477e21f60334a15 > torpidsCZwedos > gracefoster > halingrad 3rd: request: > http:// HSdir[IP] : HSdir[DirPort] /tor/rendezvous2/ Desc-ID ^^^^ here i got a 404 response >.< sorry ... if i'm doing something wrong ... if i do tell me :p

3 2

(meek|flashproxy)+(obfs3|fte|scramblesuit|...)
by Kevin P Dyer 27 Jul '14

27 Jul '14

Are there any roadblocks that prevent us from doing the following? 1. Remove the hard-coded bridge_prefs.js in the TBB. 2. Set meek as the default pluggable transport in the TBB. 3. Use meek to acquire an up-to-date bridge_prefs.js from, say, torproject.org. 4. Use the information from the acquired bridge_prefs.js to connect to Tor as normal. Ostensibly, this doesn't do a better job of hiding bridge addresses. However, it allows us to modify bridge addresses without releasing a new TBB. -Kevin

3 4

Chutney couldn't start Tor instances
by Jesse Victors 26 Jul '14

26 Jul '14

Hello everyone, I'm doing some research on Tor and I'm trying to set up a small sample Tor network to play with. I cloned the Chutney repository with /$ git clone https://git.torproject.org/chutney.git/ and then I ran /$ ./chutney configure networks/basic/ which generated the keys for each of the three authorities and also set up five relays and two clients. Everything looked good, but when I ran /$ ./chutney start networks/basic/ it says: /Starting nodes// //Couldn't launch test000a (tor --quiet -f <path>/net/nodes/000a/torrc): 255// //Couldn't launch test001a (tor --quiet -f ///<path>//net/nodes/001a/torrc): 255// //Couldn't launch test002a (tor --quiet -f ///<path>//net/nodes/002a/torrc): 255// //Couldn't launch test003r (tor --quiet -f ///<path>//net/nodes/003r/torrc): 255// //Couldn't launch test004r (tor --quiet -f ///<path>//net/nodes/004r/torrc): 255// //Couldn't launch test005r (tor --quiet -f ///<path>//net/nodes/005r/torrc): 255// //Couldn't launch test006r (tor --quiet -f ///<path>//net/nodes/006r/torrc): 255// //Couldn't launch test007r (tor --quiet -f ///<path>//net/nodes/007r/torrc): 255// //Couldn't launch test008c (tor --quiet -f ///<path>//net/nodes/008c/torrc): 255// //Couldn't launch test009c (tor --quiet -f ///<path>//net/nodes/009c/torrc): 255/ No log files are generated in <path>/net/nodes/000a, so I don't know what happened. I don't see any conflicts with ports on localhost as far as I can see. Tor version 0.2.4.22 and Python 2.7.5+ are installed. Any ideas? -- Jesse V.

2 1

Tor Research Framework
by Gareth Owen 26 Jul '14

26 Jul '14

Hi all I am releasing under the GPL a Java based Tor research framework that I have developed. The goal of the framework is to provide a simple and easy to read/modify implementation of the protocol that allows you to do things wrong. This enables researchers to try things out without trying to battle with the full tor client source or with a client that tries to help you (e.g. by proactively building circuits) - this one does as its told and no more. At present, it is a fully functional client with a number of examples for hidden services and SOCKS. You can build arbitrary circuits, build streams, send junk cells, etc. I want to build up the examples over the coming months to include sample attacks on tor (e.g. traffic pattern generators/detectors). I also want to build out the documentation to reduce the barrier to entry for researchers as much as possible. I hope it will be useful to someone - patches/pull requests always welcome! Source: https://github.com/drgowen/tor-research-framework Best wishes Gareth -- Dr Gareth Owen Senior Lecturer School of Computing, University of Portsmouth Tel: 02392 846423 Web: ghowen.me

1 0