tor-dev

tor-dev@lists.torproject.org

3581 discussions

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

Next PT/Bridges Meeting: Wednesday 15 April 0200 UTC
by isis 10 Apr '15

10 Apr '15

Hello everyone, As per the votes for the new PT/Bridges meeting time, [0] we've settled on biweekly meetings in ircs://irc.oftc.net#tor-dev, on Wednesdays, at 0200 UTC. Please let me know if this is a severe inconvenience to anyone. The next meeting will be on Wed., 15 April, at 0200 UTC, which currently translates to the following (ridiculous, antediluvian, and nationalistic) timezones: - Tue., 14 April, 1900 PDT - Tue., 14 April, 2200 EDT - Wed., 15 April, 0400 CEST - Wed., 15 April, 0500 MSK - Wed., 15 April, 1100 JT See you there! [0]: https://lists.torproject.org/pipermail/tor-dev/2015-April/008601.html -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

Fwd: [guardian-dev] Orbot v15 RC 2
by Nathan Freitas 09 Apr '15

09 Apr '15

----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: [guardian-dev] Orbot v15 RC 2 Date: Thu, 09 Apr 2015 13:24:46 -0400 Orbot v15 RC2 is out addressing some critical and *odd* issues with copy and paste of bridges, VPN refresh on network switching, dumb bug fixes related to root and transproxy settings, and one or two other odds and ends. WARNING: If you are using the "email for bridges" feature on Android, and you copy and paste the bridge lines into the Bridges setting box, you might not notice that Android somehow removes some spaces in the string. Make sure to put a space back in between the server:port and the key portion of the string. If you scan the QR codes from bridges.torproject.org this shouldn't happen. APK: https://guardianproject.info/releases/Orbot-v15.0.0-RC-2.apk SIG: https://guardianproject.info/releases/Orbot-v15.0.0-RC-2.apk.asc Source tag: https://gitweb.torproject.org/orbot.git/tag/?id=15.0.0-RC-2 /** 15.0.0 RC 2 / 9-Apr-2015 / 60f19ca **/ d6c51bc Fixes for bridge setup, and root/shell interaction - If you paste bridge addresses from Gmail, you get some strange characters c39cdcb improve root access check for transproxy 7d8eea2 switch back to DNS on 10.0.0.1, update after VPN refresh 690a8c3 Improved handling of VPN and Tun2Socks on Network Switch 9974654 fix for setting root and transproxy preferences /** 15.0.0 RC 1 / 8-Apr-2015 / 280f69dfa10c38d880e98e71954526c68f1b3df5 **/ 776b7af use loopback address e6fe252 auto-restart Tor when config changes 384fe1c fix handling of network connectivity state management 02a42e4 update translated strings 628c9d8 update tor to 0.2.6.7 906ec7f v15-beta-2 small fixes for VPN d6eb1dc fixes for network switching with VPN enabled f37b935 modifications to bridge setup strings -- Nathan of Guardian nathan(a)guardianproject.info _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscribe(a)lists.mayfirst.org

1 0

Re: [tor-dev] Tor Summer of Privacy [ Incorporating ruleset testing into https-everywhere release process ]
by yan 09 Apr '15

09 Apr '15

Oops, sending again from my torproject account. On 4/9/15 10:24 AM, yan wrote: > Hi Karan, that is great to hear. I've cc'ed Jacob, one of the current > maintainers of HTTPS Everywhere. > > -Yan > > On 4/8/15 11:40 PM, karan grover wrote: >> Hello there! >> I am Karan Grover. I am a 2nd year computer science student at IIIT >> Delhi. >> >> I am a part of my college's Cybersecurity Education and Research Center, >> which is the first of its kind in the country. I have worked primarily >> in the field of Privacy and Security of Online Social Media (PSOSM). >> >> I am interested in contributing to Tor as a part of Tor Summer of >> Privacy. The project I am interested in working on is *Incorporating >> ruleset testing into https-everywhere release process*. I have been >> understanding the codebase of *https-everywhere-checker, *and am now >> quite familiar with it. I would like to discuss further about what the >> project entails. >> >> I contribute to open source every now and then, but am now looking to be >> an active open source contributor and Tor seems to align with my >> interests. >> >> Looking forward to your reply. >> >> Thank you. >> >> >> >> _______________________________________________ >> tor-dev mailing list >> tor-dev(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev