- tor-dev - lists.torproject.org

RFC: Tor Messenger Alpha
by Sukhbir Singh 25 Jan '15

25 Jan '15

Hi, Tor Messenger is an instant messaging client currently under development. It is designed to make connections using the Tor network and will therefore be a valuable piece in the privacy-enhancing software toolkit (web: Tor Browser, email: Thunderbird + TorBirdy, chat: Tor Messenger.) Based on the Instantbird IM client [0], Tor Messenger: - sends all traffic over Tor, - uses Off-the-Record (OTR) encryption [1] of conversations by default, - can be used with a wide variety of chat networks, - has an easy-to-use graphical user interface localized into multiple languages. Some more information about Tor Messenger (and why we picked Instantbird) can be found on the wiki [2]. Current Status We have Tor Messenger bundles for Linux (32-bit and 64-bit) with OTR (using ctypes-otr [4]) and Tor support (Tor binary and Tor Launcher included), among other privacy settings. We are doing automated builds of Tor Messenger using rbm [5] (thanks to Nicolas Vigier). @@@ WARNING: NOT READY FOR PUBLIC USE. DO NOT DISTRIBUTE. @@@ Bundles Linux (32-bit) https://people.torproject.org/~sukhbir/tor-messenger-0.0.4/tor-messenger-0.… Linux (64-bit) https://people.torproject.org/~sukhbir/tor-messenger-0.0.4/tor-messenger-0.… sha256sum https://people.torproject.org/~sukhbir/tor-messenger-0.0.4/sha256sums.txt https://people.torproject.org/~sukhbir/tor-messenger-0.0.4/sha256sums.txt.a… The bundles are signed with my key (Sukhbir Singh; 0xB297B391). Extract the bundles and then run: ./start-tor-messenger. This is an early release and there may be serious privacy leaks and other issues -- please DO NOT recommend Tor Messenger to end users; this release is only for developers and advanced users who would like to help us with testing but understand the risks involved with using alpha software. Do not ignore this warning. We will try to have a monthly release cycle leading up to a stable release by July 2015. @@@ WARNING: NOT READY FOR PUBLIC USE. DO NOT DISTRIBUTE. @@@ Feedback With this release, we invite feedback not limited to anonymity leaks, usability issues, feature requests and suggestions for improvement. Please submit your feedback using the bug tracker [3] (select the "Tor Messenger" component). You can also talk to us on this mailing list or on IRC. (No seriously, don't use the bundles for any serious communication yet.) [0] - http://instantbird.com/ [1] - https://otr.cypherpunks.ca/ [2] - https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger [3] - https://trac.torproject.org/projects/tor/newticket [4] - https://github.com/arlolra/ctypes-otr [5] - http://rbm.boklm.eu/ Thanks, Arlo Breault and Sukhbir Singh

5 5

onionoo protocol changes for 'details' documents ?
by Frédéric CORNU 25 Jan '15

25 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Since today 15:30:00 (GMT+2), {guard,middle,exit}_probability fields are missing from any returned "details" document, but I cannot see anything related to this in the protocols docs [1] Any clues ? [1] : https://onionoo.torproject.org/protocol.html#details - -- Frédéric CORNU http://wardsback.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlTDsw4ACgkQieXg+ErX/wN63QD/Vf22duhpcQ/kSB1kDYz8fn5G g5oZLH6FVClZjBsSelgA/AuVDsKNecN4enQObntrzltMXVtcyferxZGKyhpemitz =mNst -----END PGP SIGNATURE-----

3 2

Event at NEXA center and next OONI dev meeting
by Arturo Filastò 23 Jan '15

23 Jan '15

Hello Oonitarians! We skipped this weeks meeting due to a lot of us being busy with an event at the NEXA center. It was a very interesting opportunity to meet a lot of great network measurement and network neutrality researchers and discuss possible areas of collaboration. I will give a brief summary of some of the most relevant things WRT OONI. # Libight hackfest On the first day we did a hackfest on libight. At the end of it we were able to produce a build of libight for iOS [1] as well as a mockup of the GUI [2]. We also finished the integration of the SOCKS client [3] that will allow us to use tor from libight. Overall we are quite close to having a working prototype for iOS and soon also for Android. # NNTools meeting Enrico Gregori and Valerio Luconi from Italian National Research Council presented their work on Portolan, that is trying to map BGP interconnections with traceroutes. They have developed a desktop and mobile application that is very cool and works well! Later we discussed about possible collaborations, in particular deploying their tests as part of our raspberry pi deployment. For the full schedule of events see: http://nexa.polito.it/nntools2015 Regarding the next developer meeting I am going to suggest we do it as usual on Monday at 19:00 CET (18:00 UTC). That's it, until next week! Have fun! ~ Arturo [1] https://github.com/alemela/libight_iOS [2] https://people.torproject.org/~art/ooni/mockups/ooni-ight-assets.zip [3] https://github.com/TheTorProject/libight/pull/71

1 0

Obfsproxy Address Translation
by Alfredo Palhares 23 Jan '15

23 Jan '15

Hello, Recently I've been fighting censorship[1] in the form of deep packet inspection. Between the OpenVPN I an obfsproxy server outside the country and a client inside the country. But what I've found out is that Obfsproxy server needs to be running as the OpenVPN server and Obfsproxy client needs to be on the same machine as the OpenVPN client. This makes stuff work but its not really optimal, since there are area of the country where internation traffic is really hard, having proper address translation would save the hassle of setting another proxy between obfsproxy and the clients would not need anything more than the OpenVPN client that they already have. I opened issue #14217[2] and would like to provide a patch for it. But I am not Python and Twisted expert, so I will be firing a few questions: - How do I debug twisted ? Given the event-diven nature of the library, how do I debug incoming packets ? - How do you write server client tests? - What part of the code is reponsible from translating the incoming packeets on the server back to the client ? Thanks in advance ! [1] https://forums.openvpn.net/topic17960.html [2] https://trac.torproject.org/projects/tor/ticket/14217 -- Regards, Alfredo Palhares

2 4

[PATCH] Fix clang warning in test code
by Tim Ruehsen 23 Jan '15

23 Jan '15

There are still 5 reports from clang analyzer. They are either false positives or (in the test code) 'easy-to-read' programming by purpose (easy to get rid of, but absolutely no need to do). Tim

1 0

[PATCH] Fix some compiler warnings (torsocks)
by Tim Ruehsen 23 Jan '15

23 Jan '15

I fixed some compiler warnings that came up with my standard gcc flags, nothing serious. BTW, the code uses some gcc extensions which are not compatible through compilers and/or systems: - pointer arithmetic with void * - function pointer and void * assignments - gcc variadic macro extensions FYI, my gcc flags are -std=gnu99 -pedantic -O2 -g -Wall -Wextra -Wstrict-prototypes -Wold-style- definition -Wwrite-strings -Wshadow -Wformat -Wformat-security -Wunreachable- code -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - Wlogical-op -Wsuggest-attribute=noreturn -Wsuggest-attribute=format - D_FORTIFY_SOURCE=2 Regards, Tim

1 0

Website Fingerprinting Defense via Traffic Splitting
by l.m 22 Jan '15

22 Jan '15

Daniel Forster wrote: > Hello Guys, > > it would be great if I could get a few opinions regarding my > upcoming master thesis topic. > > My supervisor is Andriy Panchenko (you may know some of his work > from Mike Perry's critique on website fingerprinting attacks). > As a defense, we'd like to experiment with traffic splitting (like > conflux- split traffic over multiple entry guards, but already > merging at the middle relay) and padding. > > I know that the no. of entry guards got decreased from three to one. > May it be worth the research or is the approach heading in a not so > great direction w.r.t. the Tor Project's "only one entry node" > decision? Or, actually, what do you think in general..? I think it will be interesting to see how a client of Tor can be fingerprinted by the guards chosen. In particular if the circuit length tends to be three and you perform a merge at the middle node. By watching the incoming n-tuple of guards, having chosen in advance the role of middle-hop, can clients be identified through correlation with exit traffic. I'm aware that the choice of guards can already make a client fingerprintable--but how much more so in this case. This might not be the adversary you're intending to address but is still a consequence. Unless I'm reading your proposal incorrectly. How might the possible threat be addressed. Perhaps a more robust implementation of network coding and a revisit of circuit length. I'm just throwing out thoughts. I too am interested in the application of network coding to the goals of Tor. I'll be eagerly awaiting your results. Good luck and thanks. -- leeroy

1 0

Re: [tor-dev] How Exit node decide which relay dedicated for particular http response.
by Ian Goldberg 22 Jan '15

22 Jan '15

On Thu, Jan 22, 2015 at 05:18:10PM +0100, Mohiuddin Ebna Kawsar wrote: > how "tor knows which socket belongs to which stream, and so to which > circuit" ? > which function handle this mapping?? I would guess it's the on_circuit member of the edge_connection_t struct, but others could probably give a more definitive answer. - Ian

1 0

How Exit node decide which relay dedicated for particular http response.
by Mohiuddin Ebna Kawsar 22 Jan '15

22 Jan '15

Hi, Suppose an exit node is acting as Exit for 2 different client connected by 2 different middle and guard node. suppose one of the client make http get request which will pass through Exit and TCP packet Header will be then [SENDER: EXIT NODE IP, RECEIVER: WEB-SERVER IP]. Now we have a reply from web-server. TCP HEADER [SENDER:WEB-SERVER IP , RECEIVER: EXIT NODE IP]. as this packet receiver is Exit node now how Exit node decide which relay it should pass the response data. means which client this response is for? is there any mapping or_connection to exit_connection? Regards Kawsar

2 1

lifespan of deprecated "ORListenAddress" configuration option
by Frédéric CORNU 22 Jan '15

22 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear all, The Tor Manual [1], as of today, says that ORListenAddress option is deprecated and that same behaviour can be achieved by specifying the listening address within the ORPort option. Although using ORPort to specify listening address works as expected whit tor, it causes arm to crash, see ticket #9269 [2]. You guys know how much relay operators rely on arm to check on their babies, and having tor operate on a specific IP address may not be such an uncommon practice. I don't know how both tor and arm projects coordinate their efforts, if they do, so the big question is : Can users expect support for ORListenAddress at least untill ticket #9269 is closed ? That would be nice [1] https://www.torproject.org/docs/tor-manual.html.en [2] https://trac.torproject.org/projects/tor/ticket/9269 - -- Frédéric CORNU http://wardsback.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlTAlLYACgkQieXg+ErX/wOKSAD+KFKO90dK0oMgW+lOOJ30TiEL Jxe4re8n4KUuKcEE1yYA/RHdxiyjH56yIR8lzmBIDyIouHgKd+xB2CvLLelJ5CDR =zrhG -----END PGP SIGNATURE-----

2 1