- tor-dev - lists.torproject.org

Re: [tor-dev] Fwd: Orbot roadmap feedback
by Nathan Freitas 13 Jan '16

13 Jan '16

On Tue, Jan 12, 2016, at 11:52 AM, Michael Rogers wrote: > On 12/01/16 16:16, Nathan Freitas wrote: > > The broader idea is to determine which Tor torrc settings are relevant > > to the mobile environment, and that could use a more intuitive user > > interface than the empty text input we currently offer in our Settings > > panel. This may also mean implement a slider type interface mechanism > > similar to Tor Browser. In addition, users are interested in being able > > to control which network types (wifi vs 3g) Orbot runs on, in order to > > conserve spending on bandwidth. > > Briar's TorPlugin has an option to disable Tor when using mobile data, > feel free to backport it to Orbot. Likewise for the plugin as a whole, > if it would be a suitable basis for LibOrbot. We've benefitted a lot > from your work and I'd love to send some contributions back upstream! Is TorPlugin already a distinct library / module? +n

2 1

Needs Code Review: Shared Randomness Generation for Tor
by George Kadianakis 13 Jan '16

13 Jan '16

Hello there, we are happy to tell you that we finished coding proposal 250 and our first attempt at implementation is ready for review. You can find the final specification here: https://gitweb.torproject.org/user/dgoulet/torspec.git/log/?h=prop250_final… and the corresponding code here: https://gitweb.torproject.org/user/dgoulet/tor.git/log/?h=prop250_final_v1 Trac ticket #16943 (https://trac.torproject.org/projects/tor/ticket/16943) will be used for code review. Please use this mailing list to discuss any issues with the spec. Some notes: We've separated this in 7 commits prefixed with prop250: except first one that adds a needed tor_htonll/ntohll function to tor utils. This code is mostly contained in two *new* files (with their headers) that are shared-random.{c|h} and shared-random-state.{c|h}. For what it's worth, we expect this code to run for a long time before the shared random values generated by the authorities are used for anything (e.g. HSDir scrambling). Cheers!

3 3

Questions about censorship detection paper
by John 13 Jan '16

13 Jan '16

Hi, I ran into the technical report from George Danezis about an anomaly-based censorship-detection system for Tor. I have a few questions that I hope you can help me with. Is there an implementation available of the approach described in the paper? The paper talks about finding anomalies in the time series of the number of requests to directory servers from certain jurisdictions. Where can I find this data about the requests to directory servers? --john [1] https://research.torproject.org/techreports/detector-2011-09-09.pdf

2 3

Fwd: Orbot roadmap feedback
by Nathan Freitas 12 Jan '16

12 Jan '16

I've got big plans for Orbot in 2016... any thoughts on the roadmap below, particularly how it aligns with Tor core roadmap, would be appreciated. ----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: Orbot roadmap feedback Date: Mon, 11 Jan 2016 22:58:05 -0500 Here is my current set of brainstormed ideas for Orbot that I am currently working through... please add, edit, improve and prioritize as you are willing and able. - Continued inclusion of the latest and greatest pluggable transports (Obfs*, Meek, ???) - Improved support for requesting and configuring Obfs4 bridges - directly integrate with BridgeDB to provide streamlined way for people to get bridges where Tor is blocked - More Orbot VPN features including better UI for enabling/disabling Tor routing, blocking specific apps, ports and/or hosts, and general "firewall" or little snitch type features within the Orbot VPN - OrbotShare: an OnionShare inspired file sharing and download manager service to enable easy hidden service .onion setup and sharing (including support for new ephemeral onions) - OrbotRelay/Bridge: improved UI for running a bridge or relay from within Orbot, including support for scheduled times (night only) or states (only when plugged in, on wifi, and screen is off, etc) - Removal of Polipo, in favor of new streamlined in process HTTP proxy (less memory use, and more stable) - Creation of LibOrbot module/library for use by any app to embed Tor into their app - Overall improved configuration / settings UI to make tuning Orbot a better, simpler experience... this is an expansion of the new exit country selector in Orbot v15.1, but also includes managing things like network usage and so on. - OrbotWear / OrbotTV: Should we expand Orbot support to other Android platforms like watches and Smart TVs? Perhaps Orbot relay/bridge mode could run on a TV or set top box? - Some sort of "Pro" or Donation-ware version to allow a pay-what-you-can concept within the app Good, bad, ugly? Let me know! -- Nathan of Guardian nathan(a)guardianproject.info

3 2

Propsal 263 Quantum-safe Hybrid handshake for Tor, updated feature request
by Zhenfei Zhang 12 Jan '16

12 Jan '16

Hi list, Thanks for all your valuable comments. We have updated the feature request following your comments. Please see the attachment for the updated feature request, and see https://github.com/zhenfeizhang/ntru-tor/commit/0354fe1d61b2b79615301ff387e… for the modification over last version. Thanks for your time, and please let us know if you have any further comments/suggestions. Cheers, Zhenfei

2 1

Summary of meek's costs, December 2015
by David Fifield 11 Jan '16

11 Jan '16

Here's the summary of meek's CDN fees for December 2015. App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 November 2014 $224.67 + $362.60 + $0.00 = $587.27 December 2014 $326.81 + $417.31 + $0.00 = $744.12 January 2015 $464.37 + $669.02 + $0.00 = $1133.39 February 2015 $650.53 + $604.83 + $0.00 = $1255.36 March 2015 $690.29 + $815.68 + $0.00 = $1505.97 April 2015 $886.43 + $785.37 + $0.00 = $1671.80 May 2015 $871.64 + $896.39 + $0.00 = $1768.03 June 2015 $601.83 + $820.00 + $0.00 = $1421.83 July 2015 $732.01 + $837.08 + $0.00 = $1569.09 August 2015 $656.76 + $819.59 + $154.89 = $1631.24 September 2015 $617.08 + $710.75 + $490.58 = $1818.41 October 2015 $672.01 + $110.72 + $300.64 = $1083.37 November 2015 $602.35 + $474.13 + $174.18 = $1250.66 December 2015 $561.29 + $603.27 + $172.60 = $1337.16 -- total by CDN $8607.22 + $9064.72 + $1292.89 = $18964.83 grand total https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… The number of users increased by about 1,000 in December 2015. meek-google had an outage as a result of a server migration between 23 November and 4 December. I set up a bridge that is not rate-limited. If you use it, your meek will go a lot faster. https://bugs.torproject.org/17890 The catch is that you have to set up a CDN or upload a PHP file yourself. Here are some docs to look at: https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtorunameek-server… https://trac.torproject.org/projects/tor/wiki/doc/meek#GoogleAppEngine https://trac.torproject.org/projects/tor/wiki/doc/meek#AmazonCloudFront https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure == App Engine a.k.a. meek-google == Here is how the Google costs broke down: 2528 GB $303.39 5158 instance hours $257.90 Compared to the previous month: 2162 GB $259.52 6856 instance hours $342.83 https://globe.torproject.org/#/bridge/88F745840F47CE0C6A4FE61D827950B06F9E4… == Amazon a.k.a. meek-amazon == Asia Pacific (Singapore) 56M requests $67.98 425 GB $58.83 Asia Pacific (Sydney) 2M requests $3.37 10 GB $1.41 Asia Pacific (Tokyo) 30M requests $37.14 242 GB $31.64 EU (Ireland) 142M requests $171.48 968 GB $76.50 South America (Sao Paulo) 5M requests $11.03 31 GB $7.46 US East (Northern Virginia) 86M requests $86.54 635 GB $49.88 -- total 324M requests $377.54 2314 GB $225.72 https://globe.torproject.org/#/bridge/F4AD82B2032EDEF6C02C5A529C42CFAFE5165… == Azure a.k.a. meek-azure == Zone 1 1560 GB $135.71 Zone 2 267 GB $ 36.89 -- total 1827 GB $172.60 https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8… Earlier reports in this series: https://trac.torproject.org/projects/tor/wiki/doc/meek#Costs

2 5

Transparent proxying: automagically add firewall rules
by Rene Bartsch 11 Jan '16

11 Jan '16

Hi, transparent proxying to TOR Hidden Services is a great feature of the TOR daemon when it comes to other applications/protocols than HTTP and surfing. It would also be great with privacy appliances (e.g. Mailpile using TOR as secure SMTP transport channel). John Does have problems with such a setup because of the NAT firewall rules. So I suggest the TOR daemon should automagically set the necessary NAT-rules on Windows, Linux and BSD when "TransPort" and "VirtualAddrNetworkIPv[4|6]" are configured in torrc. -- Best regards, Renne

2 1

Tor Control Protocol: multiple commands in a single line possible?
by Patrick Schleizer 11 Jan '16

11 Jan '16

TLDR: Does Tor's control protocol actually support something like ; ? I.e. something like signal newnym ; getinfo address ? How many of there separators are there? Can you provide examples please? Background: At the moment we are implementing support for whitelisting wildcards for control-port-filter-proxy-python [0] to support Onionshare and Ricochet. [1] [2] [3] [4] Does Tor's control protocol actually support something like ; ? If it does, then this would complicate the wildcard feature. If we whitelisted the wildcard add_onion *, we don't want it to match some hypothetical feature add_onion * ; .... I.e. not add_onion * ; GETINFO address. (If it was the case, then we would have to limit the wildcard (*) from example SETCONF HiddenServicePort * to exactly one [numeric] argument etc. Or better, correctly parse multi lined commands. Or as stopgap, reject these separators since no applications using Tor's control protocol are currently using those.) Cheers, Patrick [0] https://github.com/Whonix/control-port-filter-python https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy [1] https://phabricator.whonix.org/T446 [2] https://phabricator.whonix.org/T445 [3] https://www.whonix.org/wiki/Next#onionshare [4] https://phabricator.whonix.org/T448 (Asked Roger by mail, said it's okay to post this on tor-dev.)

4 3

Tor metrics: Questionable relays-by-platform accounting
by Fabian Keil 09 Jan '16

09 Jan '16

Looking at "Tor metrics - Relays by platform" [0] one could think that the number of "FreeBSD" relays is only slightly lower than the number of "Windows" relays. It also looks like the number of "other" platforms is constantly zero while the number of "Darwin" relays is unclear (but potentially zero as well). Obviously that's incorrect: fk@r500 ~ $sudo -u _tor grep platform /usr/jails/tor-jail/var/db/tor/cached-descriptors | cut -w -f 5 | sort | uniq -c | sort -rn 6662 Linux 555 Windows 286 FreeBSD 83 OpenBSD 25 Darwin 10 NetBSD 4 SunOS 4 ElectroBSD 4 Bitrig 2 DragonFly 1 GNU/kFreeBSD 1 CYGWIN_NT-10.0-WOW Is it possible that the "Tor metrics" count everything but "Linux" and "Windows" as FreeBSD? Fabian [0] https://metrics.torproject.org/platforms.html

3 6

Proposal: Stop giving Exit flags when only unencrypted traffic can exit
by Tom van der Woerdt 08 Jan '16

08 Jan '16

I've had this on my todo list for a while, finally wrote it down. Honestly, it's a minor change, but something that imho needs to be done. Torspec branch: https://github.com/TvdW/torspec/commits/exit-flag-not-all-plaintext Full text below, tldr first: replace [80,443,6667] with [80,443,5222] for Exit flagging. =================== Filename: 264-exit-flag-not-all-plaintext.txt Title: Stop giving Exit flags when only unencrypted traffic can exit Author: Tom van der Woerdt Created: 2016-01-05 Status: Open 1. Introduction Tor's Exit flags are assigned to relays that have an exit policy that allows exiting to at least two out of three pre-defined ports: 80, 443 and 6667. Since 80 and 6667 (resp. http and irc) are generally used for unencrypted traffic, an attacker could construct an exit policy that relays only unencrypted data. 2. Changes 2.1. Exit flagging By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry, Exit flags can no longer be assigned to relays that exit only to unencrypted ports. 2.2. dir-spec.txt A change to dir-spec.txt will be needed to change port 6667 to 5222. 3. Migration This change only needs to be rolled out to directory authorities. Since the flagging system is simple, no special migration is needed for this change, and it will take effect as soon as the deployment of the change has reached a sufficient number of directory authorities. 4. Other considerations While it would have been ideal to drop the port 80 condition as well, in the current state of the internet this is not likely to be a good idea. Too much websites still use unencrypted connections. However, this may be worth reconsidering every few years. XMPP was chosen to replace IRC because nowadays unencrypted XMPP is rare, and because the XMPP protocol is slowly gaining popularity within the communities on the internet. Other popular ports have been considered, such as 22 (SSH), 465 (SMTP), or 995 (POP3), but these are unlikely to be good candidates because of wide spread bruteforce attacks on these ports. =================== Tom

8 16