- tor-dev - lists.torproject.org

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

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

11 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 George Kadianakis wrote: > 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-encrypted-services.txt >>> >>> >>> >>> Feedback would be greatly appreciated. >> >> First thanks for that! Really useful stuff. >> >>> >>> Here are some specific points that I would like help with: >>> >>> - Should we require a specially compiled version of Tor to >>> enable this feature? Like we do for tor2web mode? In this >>> proposal, I didn't require any special compilation flags. I >>> don't have strong opinions here. >> >> IMO, I'm not sure this is useful. This feature requires prior >> knowledge of the HS operator to know what's a "Direct Onion >> Service" and decide that she wants that for her service. Thus, a >> torrc option seems enough. I don't see any reasons for this >> option that will limit deployment. >> > > Yes, I also feel the same. > > My main fear is sample torrc's that are being posted around the > net and people just copy-paste them into their box: someone might > not notice the DirectOnionServiceEnable option. Perhaps this could be mitigated by alerting the user the first time Tor is started with this option enabled. This is obviously harder to do if Tor is started as a service, but it should be possible for manually-started Tor or TBB. >> >> [snip] >> >>> >>> 3.2. One-hop circuits [ONEHOP] >>> >>> When in this mode, the onion service establishes 1-hop circuits >>> to introduction and rendezvous points. The onion service SHOULD >>> also ignore cannibalizable 3-hop circuits when creating such >>> circuits. >>> >>> This looks like this for the rendezvous point case: >>> >>> |direct onion service| -> RP <- client middle <- client guard >>> <- |client| >>> >>> This change allows greater speeds when establishing a hidden >>> service circuit and reduces round-trip times. As a side-effect, >>> busy onion services with this feature cause less damage to the >>> rest of the network, since their traffic gets passed around >>> less. >> >> Would it be possible to drop the rendezvous part where the client >> could simply connect to the IP and then the circuit back to the >> HS would be used? (Though that would require that the client >> knows the HS it's trying to reach is a Direct Onion Service, >> could be mention in the descriptor?...) >> > > I think that's indeed possible, but would require multiplexing > multiple client connections on a single IP circuit, which Tor > cannot do at the moment AFAIK. It is my understanding that it's not > an easy change, but I'm pretty sure that I2P and other projects are > doing it, so we could in theory take a look at how those guys do > it. I2P does have the ability to run "zero-hop" tunnels, yes - the router simply provides its own details for the tunnel entry point. But this probably isn't directly helpful for Tor because I2P is a packet-switched network, and it doesn't use separate rendezvous points for individual connections between Destinations. For high-traffic services that don't require anonymity, we generally recommend using one-hop tunnels instead of zero-hop. This is primarily to avoid connection limits being exceeded on the hosting router. The speed hit of having an additional hop in the path is generally outweighed by the benefit of only having e.g. 8 incoming connections for a particular service, instead of several thousand. It therefore also helps to mitigate DDoS attacks (although the biggest of services e.g. Facebook would likely have their own systems that would better handle this). str4d > _______________________________________________ tor-dev mailing > list tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVKGTIAAoJEBO17ljAn7PgYg8P/1gn8BleY9GyuceCXCvVicwk ROWeEahM/ujSzpJXqjTJMBjuBcXocan/RHbeTyrfjCGZhj4p/eUMKnXpMBpJcuKp oKEDXP3n14tnUxTnUT7vRl4ZYGmCZAiIKUqeqwAz2/1LxKYK+IDsxaurnbOA5uXV vuL2Q8WxbnhExEr+lvRX4zV2/5hGK7jj5R1Hz35qxZsJTjPUu3mRXxS5aiExUfzS kjxUA5uevKdE6/K0nQ4hJ7rY3ZkfcD8YIsW7CQsC0FfK8DXMaPew+tvUsUuegeDt nbIFRx8oGItFwDDwZIUWZED2g60YhrSc7Ig192amXYe42GtoPQC3n6ul0GqNM2cb m5AJAw5GGlxluprAwu3AcVl3/kYCLqN50bK/Lz3f2bBcYuUvcbNJ5GK6F4W/ye45 Pl2QmiiaGuZM5CKWNY4/kHc3sJaPfnFvbxdocqcIok3/AlnhVotQVDTl7bFklYOP qJ58oNJAU2UHY+uOX6c+8+d2G062AbWxo4iFlXOGguNSKnR+3w0fE+P+lMQjtAGj cE/7zj/DcFrj9TpVoZBAiDrEJfkWxywASoHhe1Y/eayzDg1D/jqfNNJ9/0YnPWPd tC/pnHPQ1/gc9mqIJzmW1c9tKdwzys1UI9UGNjdggVn80dnXYyE5xAwx5Ymh11NT VzHWkgab7+Shrp4dQL3a =B87T -----END PGP SIGNATURE-----

1 0