- tor-dev - lists.torproject.org

Summer of Privacy applicant, Multi-threading
by Kim Reece 15 Apr '15

15 Apr '15

Hello, I see several folks doing brief intros here so I'll do so as well. Most of my application is in already, just finishing up the patch. I'm a Mathematics undergrad, 3rd year come Fall. I've used multi-threading in coursework and in an internship I did at JPL/NASA. I want to expand the multi-threading in Tor this summer. For my patch I'm working on #3569 (Refactor socks parsing). It won't be a complete implementation of that bug this week, but I aim to complete the first part of it, ie. the refactoring internal to the function to expose the state model clearly in code structure. To that end I have one quick code style question: Is clarity preferred over the (very short) body of a conditional only occurring in one place? I'm encountering at least once instance where the choice is between repeating a (very short) code block, thereby introducing the potential that one section of it may in the future be edited without the other receiving the same edit (even though they're right next to each other), or retaining a gnarly conditional that took a truth table for me to be sure I had the right end of. If code occurring exactly once is a priority, the gnarliness can be repaired with an explanatory comment, but I'd like to know which is preferred. Thanks, -- Kim

1 0

Using consensus package versions for third party software
by John Brooks 15 Apr '15

15 Apr '15

Proposal 227 added a method for putting non-little-t-tor package versions and digests in the consensus, intended to authenticate Tor Browser updates. This is done in tor 0.2.6, although it’s not yet in use by Tor Browser or the consensus. I propose using this feature to notify Ricochet[1] users of software updates. My reasoning is: - It’s vital to the security of Ricochet’s users that they’re quickly notified of version updates - Tor is the only infrastructure Ricochet uses; adding an “update server” would harm its model - The consensus-based method is better than anything we can independently do - I think Ricochet is an ideal case of where this work can be useful The benefits from my side are obvious, but it’s less clear if this is appropriate for Tor. Ricochet users[2] are an extremely small portion of Tor’s users, but this would be in every consensus. Some directory authorities would have to volunteer to keep those votes up to date. I’m interested in feedback from the community in general, and especially from directory authorities on whether this is something they’d be interested in supporting. Of course, even if people think this is a good idea, the burden is on me to convince DAs to lend their time. Thanks, - John [1] https://ricochet.im/ [2] It’s part of the design that I can’t accurately count users. My best guess is “low hundreds, and growing”.

1 0

Fwd: Orbot v15 RC3... now with x86/ATOM-power!
by Nathan Freitas 14 Apr '15

14 Apr '15

----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: Orbot v15 RC3... now with x86/ATOM-power! Date: Mon, 13 Apr 2015 09:55:44 -0400 Making some tiny changes to external/Makefile and jni/Application.mk means we can now build the tor, polipo and xtables binaries, along with the tun2socks.so for any necessary chip architecture. I've added support for x86 in this release, which only added a few MB to the overall APK. Somehow, devices with Intel ATOM chips were able to run Orbot v14 releases, even though we didn't target x86. I think ATOM has some sort of light ARM compatibility mode, but we broke that in the update for v15... anyhow, this is better, as it is officially supported and tested. One interesting issue is that GoLang 1.4.1, which we are using to cross-compile the Meek and Obfs4 pluggable transports to Android, only supports targeting Android ARM for right now... I assume that will change soon, but if not, we may have to add Obfsclient back into Orbot for supporting x86 devices. The most popular x86/ATOM devices we have heard people complaining about seem to be Galaxy Tab 3 and the Asus Zenphone and Padphone devices. Anyhow... details below... **** APK: https://guardianproject.info/releases/Orbot-v15.0.0-RC-3.apk Sig: https://guardianproject.info/releases/Orbot-v15.0.0-RC-3.apk.asc Tag: https://gitweb.torproject.org/orbot.git/tag/?id=15.0.0-RC-3 /** 15.0.0 RC 3 / 13-Apr-2015 / b941a1c7d5588db7efd9fab672ec518a69f76f84 **/ b941a1c show warning about bridge limits on Intel x86/ATOM devices 325ca1f only ARM chips can support the new Obfs4, Meek bridges so hide the UI options that promote them, and just request standard br i 3c6f173 make buttons not resize weirdly with long strings 421764b make socksbypass local port random 4ab1854 update resource installer to handle different architecture e7a7d8c support variable arch builds to support x86 move asset builds to /assets folder 74deb39 support building tun2socks for x86 933b2e9 Small VPN and socket monitoring related fixes -- Nathan of Guardian nathan(a)guardianproject.info

3 2

Re: [tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"
by teor 13 Apr '15

13 Apr '15

> Date: Fri, 10 Apr 2015 15:47:23 +0300 > From: George Kadianakis <desnacked(a)riseup.net> > > David Goulet <dgoulet(a)ev0ke.net> writes: > >>> On 09 Apr (21:58:49), George Kadianakis wrote: >>> Hello, >>> >>> I inline a proposal for Direct Onion Services. It's heavily based on >>> the "encrypted services" proposal of Roger, but I refined it, made it >>> more proposaley and enabled a few more optimizations. You can find the >>> original piece here: >>> https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypte… >>> >>> Feedback would be greatly appreciated. >>> [snip] > >>> >>> - We really really need a better name for this feature. I decided to >>> go with "Direct Onion Services" which is the one that the NRL people >>> suggested here: >>> https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html >>> I'm not super happy with it, but I can't think of better ones myself. >>> Here are some candidates: >>> 1 Way Anonymous Hidden Services >>> Fast Onion Service >>> Short-circuited Onion Services >>> Fast-but-not-hidden Services >> >> "Fast Onion-Space Service" was proposed by pfmbot on #tor-dev. I like it >> because it describes pretty much what it is and the acronym is FOSS. :) > > It's not clear to me why acronym collisions are a plus :) > >>> >>> - We also need a better torrc option. If the name of this feature does >>> not portray its dangers, then the torrc option should be a bit >>> terrifying. That's why I went 'DangerousDirectOnionService' which I >>> actually don't like at all. BTW, it's unclear whether this mailing >>> list is the best place to brainstorm for names. >> >> This one depends on the name quite heavily but I don't think we should >> have a scary name. Scary name seems to me they will simply bring more >> questions without context of the actual feature. What is "Dangerous" >> about this, why is it in Tor at all?... This could simply be resolved by >> clear and thorough documentation of the risks/benefits of the options. >> >> For instance, we could *not* put it in the default torrc file and thus >> will only be in the man page with *good* documentation. Like you said >> also in the proposal, a big warning is very important at boot. >> >> If it's off by default and not present in the torrc file, there are no >> reasons why someone would enable this just because it's says >> "DirectOnionServiceEnable". (Ok I might be an optimist but still, we are >> not that responsible for reckless HS operator ;) > > Yes, I agree that the 'Dangerous' prefix is stupid. I think I'm OK > with changing the proposal to use 'DirectOnionServiceEnable' but I would > prefer if it's a bit more alarming. >> >> [snip] I've been hesitant to weigh in on the naming conversation for hidden services. But I am concerned about the issues raised in the previous few emails on the topic. Matt @ Speak Freely has a strong point about acronym collisions - they only serve to confuse users and dilute the search space. And usability becomes a security issue as soon as names are confusing to users. Others have also made important points about how we name things in general. So I'd like to propose some general naming principles, mostly distilled from recent conversations about names: 1. Avoid acronyms that collide with popular acronyms, particularly those in the security / software / technology spaces. 2. Names should be kept consistent across the entire Tor code base and ecosystem. 3. When selecting option, feature, and concept names: A) Names should describe the most important user-visible impact of an option, feature, or concept. B) If the feature has a serious impact on anonymity (or other typical user assumptions), the name should indicate that. C) Names should avoid specific implementation details, as these may change. D) Names should avoid giving relative opinions on performance, security, or privacy impacts, as these are often dependent on context. E) Project names are an exception to principle 3, and should have abstract names, or descriptive acronyms. My evaluation of the suggestions around hidden services / onion services based on these principles is: > Onion Service Collides with OS, or Operating System, violating principle 1: no collisions. If we decide to disregard this acronym collision, and accept the usability impact, every option and the entire manual page should be changed in the same release, to satisfy principle 2. This would involve a transition period in which both HS and OS options would work. (We should also consider the usability of options with OS in the name before making the switch.) > Direct Onion Service > Dangerous Direct Onion Service As it's already been noted, these collide with DOS and DDOS (1), and don't describe which end is direct (3A & 3B). > Fast Onion Service > Short-circuited Onion Services I'm concerned about the collisions with OS implied by these acronyms (1). Also, the first provides a performance goal (3D), and the second, an implementation detail (3C). Neither describes the most important user-visible behaviour - lack of server anonymity (3B). > Fast-but-not-hidden Services This seems to combine a performance goal (3D), with a description of the impact of the service. Aren't we better to address the speed / anonymity trade off in the manual and other documentation? > 1 Way Anonymous Hidden Services This is descriptive (3A & 3B), but which end is anonymous? Why not state that it's the client: Client Anonymous Hidden Services Or, even better, state that the server is non-anonymous: Exposed Server Hidden Services Public Server Hidden Services Yielding option names like the following: ExposedServerHiddenServiceEnable PublicServerHiddenServiceEnable But I'd be happy with any feature and option names that make it obvious that the hidden service server has reduced anonymity compared to standard hidden services. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED

2 1

Re: [tor-dev] Fwd: Orbot v15 RC3... now with x86/ATOM-power!
by Nathan Freitas 13 Apr '15

13 Apr '15

On Mon, Apr 13, 2015, at 02:05 PM, Daniel Martí wrote: > Possibly stupid question, but wouldn't a static linux/x86 binary work > just fine as long as you're executing it directly? As far as I know the > Android port is just for all the bindings involved in e.g. writing a > game in Go that does OpenGL calls back to Android. There a few more changes in there, as well, such as how DNS works on Android, and few other small underlying differences. > > For example, I found this bit in a blog post online: > > > Copy myexectuable under your Android project’s ./libs/armeabi/ folder. > > If you’re targeting one of the rare x86 Android devices, build to > > x86/Linux and copy the resulting binary to ./libs/x86 (and yes, you > > can include both in a single APK, and it will deploy whichever one is > > appropriate). > > But then this would mean that we wouldn't need android/arm either, since > we could just use linux/arm instead :) We were previously using linux/arm for the PT compiling, and it mostly worked, but it turns out there are enough small differences in the Android API from Linux, that it does matter to target Android specifically. This is similar to why we need the Android NDK for tor cross-compile, and not just a generix linux ARM build. +n

2 1

Re: [tor-dev] Fwd: Orbot v15 RC3... now with x86/ATOM-power!
by Nathan Freitas 13 Apr '15

13 Apr '15

On Mon, Apr 13, 2015, at 12:57 PM, Yawning Angel wrote: > On Mon, 13 Apr 2015 10:14:43 -0400 > Nathan Freitas <nathan(a)freitas.net> wrote: > > One interesting issue is that GoLang 1.4.1, which we are using to > > cross-compile the Meek and Obfs4 pluggable transports to Android, only > > supports targeting Android ARM for right now... I assume that will > > change soon, but if not, we may have to add Obfsclient back into Orbot > > for supporting x86 devices. > > Hmm, maybe I should add obfs4 support to obfsclient. I have code for > all of the crypto I would need to add. Let me reach out to the GoLang Android community and see what the blocker is... I was thinking the same thing though, it wouldn't be hard to still support Obfsclient, along with the Go-based PT's. Thanks!

2 1

project related
by raj kumar 13 Apr '15

13 Apr '15

hi , i am a second year BSc.cs undergraduate student and i am very much interested in doing a project on tor's ''profile UDP transport protocol''. But since i am new to this project thing, i am really in need of ideas and suggestions to accomplish this. It would be great if u can help me with this project. Thank you.

1 0

TSOP proposal
by Rémi py 12 Apr '15

12 Apr '15

Hello tor-dev, I'm a master student researching computational stylometry (analyzing writing style of typed texts) in adversarial settings. Computational stylometry is a danger to the anonymity of authors who do not take appropriate precautions. A draft TSOP proposal is attached, it builds upon my academic research. I mailed tor-assistants about my TSOP proposal and Damian informed me that it might be difficult to find a mentor for this project. I am mailing tor-dev in the hope of finding someone who is willing and able to be my mentor for this TSOP project. The application that I would like to write will be my first non-web application that targets non-technical users (as opposed to academic users). A lot of machine learning and NLP will be used, but I don't need a mentor for that. Although I have mostly worked in groups (academic and professional) I have carried this research project myself and I am confident in my ability to continue to do so. If you have any questions please contact me. Hoping to find a mentor for this project, Kind regards, Rémi.

1 0

Are DAC_OVERRIDE & CHOWN capabilities required for ControlSocket?
by Nusenu 12 Apr '15

12 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, tor will fail to startup with the current systemd service file [1] if your torrc makes use of the ControlSocket feature. To work around the issue one has to additionally allow the following capabilities: CAP_DAC_OVERRIDE CAP_CHOWN since the socket file is create as root and then changed to the tor user (chown). Is it possible to change this to not require CAP_DAC_OVERRIDE and CAP_CHOWN capabilities anymore? thanks, Nusenu [1] https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in#n 26 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVKmkiAAoJEFv7XvVCELh0Qk8QAITqZiFwp+nBIywWgLLQ5m6K CNkRa+HcNk3sCJKFWOzXqLP4Q1mIUrPWT6Mm+LbwLvo8uRnJqBNL5H0F+kDgYfyO wAsnRicwmoNfHa8hb292nj4p4eV/gQf9J94/creDl99jrtlgYBeLWY8toUZy452x QvAny7EC9Gt06/zMyNJxvVhb1SgthLsIfN6LXizH0Xe1y6m1Kh4XW/py5nvuMwmR sZg1QyUxQ8uJIs73J0KnuGZrzloJGN6IZmJ4EZ250gTUty3VtgvOTAu7W6KsGC2F dyHFqbJqHnEPLUn2ITxcmxBGduG7TWueh1+2KElVMQI9+j8IsD+9xGHUPtiywVEJ VpxaUlDqOu0tNovRPzkM01pg9KTqvydJ7BgAV0GgpoAH1rnYuEIh+kqieHvOLN96 uSuOjzTD87sHClWfIhuf645GCK+iy2Ln6f8yzxZn2DT870/yraX7eCaAK6gQt803 FMdBY2qtw3rFuGMW9ca/LTGlu04BrQb/boIEMhUMLdfAdBbJxYPuTbKbtBCbfcew NtB+5sxAuy2o8XcHsX/6gjDBi4rb7xp5QKy5xgsavE+uqyXAwCKNFF5yT7HNYX33 UMnSG1069frMXAGTYAPzQp+7dVLGs6h+xPx8aut/SoZqHjQOxQ6Qv5PtgltRvfv3 ZsOrqE5a0aly6OsspTUN =/5TL -----END PGP SIGNATURE-----

2 2

Big performance improvement for meek-azure
by David Fifield 12 Apr '15

12 Apr '15

I found and fixed a big performance limitation in the meek-azure transport. If you tried meek-azure before, but it was too slow, give it another try! meek-azure has always seemed slower than the other two backends, and I recently spent the time to figure out why. It was a lack of persistent HTTP connections between the Azure host and the Tor bridge. Every single HTTP request was doing a complete TCP and TLS handshake. This of course increased latency, but the bottleneck was actually CPU on the bridge, as it tried to cope with all those TLS handshakes. Here is the commit that causes connections to be shared and reused: https://gitweb.torproject.org/pluggable-transports/meek.git/commit/?id=e06b… This issue did not affect meek-google because the App Engine URL fetch API reuses HTTP connections transparently. It did not affect meek-amazon because the CloudFront CDN does its own connection reuse. Usage on meek-azure has already increased in the past few days since I started testing the change. I attached a graph that shows the all-time bandwidth history of the bridge. https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8… David Fifield

1 0