- tor-dev - lists.torproject.org

Static compile config and incore runtime [HS via Control Port]
by grarpamp 17 Feb '15

17 Feb '15

In situations where it is inconvenient / impossible to manage / rely a bunch of library files, dropping a static compiled tor in place is handy. Similarly, it should be possible to completely configure and run tor in that one static binary and in ram... no other files at all (torrc, geoip, .tor state dir, etc)... depending on your config. It may be necessary to compile in a basic torrc just to get tor going, before you can spawn a control port. Other torrc/commandline options may not as of today be available via the control port... so they would need compiled in and just run './tor' . In some unique situations you may not even be able to spawn/access the control port. So ability compiling in HS keys etc would be useful there. There may already be some tickets for these things.

2 1

Tor Project Idea | GSOC 2015 | Panopticlick | fake fingerprint
by Rohit Dua 15 Feb '15

15 Feb '15

Hello I'm Rohit from India, aspiring for gsoc-2015(TOR). This will be my 2nd consecutive year for gsoc participation. Previous mediawiki. Project:BUB tool <http://tools.wmflabs.org/bub/> I stumbled across Panopticlick related project <https://www.torproject.org/getinvolved/volunteer.html.en#Panopticlick> in tor project ideas. I would like to propose a project relating to this. Panopticlick obtains browser fingerprints mainly via javascript objects(navigator, screen, window etc.) These objects are easy to fake in webkit browsers, without touching the underlying source code of browsers, eg. using *__defineGetter__() *after every* javascriptObjectCleared.* If we could compile a large dataset of possible values of js object for several popular browsers, we could use that to randomize the fingerprint for each network request. The dataset could also contain random http header values etc. I am building a python library that does somewhat similar. https://github.com/rohit-dua/selkie (*in development*) It uses pyqt for headless browsing/scraping of webpages. It is a python library that mimics different browser fingerprints by faking(randomizing) the values of navigator, screen object, headers etc. I also intend to add biometric library that mimics humans mouse movements/ keypress statistics for clicking links and surfing pages. I propose to build a similar headless bot that mimics several browsers fingerprints and could be used for anonymous scraping of data and/or adding a feature of random fingerprint in awesome tor tools. Also to improve anonymity location based datasets could be provided(*supported in the above library*) as extra/feature.(maybe downloaded from statcounter.com) Thanks Rohit Dua IRC:rohit-dua github: rohit-dua <https://github.com/rohit-dua/> (8ohit.dua(a)gmail.com)

5 6

Fwd: Orbot v15-alpha-3 with VPN and Meek!
by Nathan Freitas 14 Feb '15

14 Feb '15

----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: Orbot v15-alpha-3 with VPN and Meek! Date: Sat, 14 Feb 2015 02:57:34 -0500 More progress on Orbot VPN support, and now, thanks to our new PLUTO library (https://github.com/guardianproject/pluto) support for Meek (https://trac.torproject.org/projects/tor/wiki/doc/meek) and soon Obfs4 as well. Currently you can use Meek or you can use VPN, but you can't use both together... still working on that, as I can't get Meek to talk to the passthrough HTTP proxy I use to allow socket connections out of the VPN filter. To use Meek, just enable the "Bridges" button on the home screen, without using any bridge config info, and it will default to using the Meek Azure instance. If you set the bridge line to 0 it will use Google, and 1 it will use Amazon, and 2 it will use Azure. The VPN mode is just as easy, just enable VPN using the homescreen toggle button, then start/restart Orbot. All apps on your phone should now be running through Tor. Remember, Bridges and VPN don't work at the same time, for now... but please test both features separately, and let me know how well they work for you. APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk.asc Source: https://gitweb.torproject.org/n8fr8/orbot.git/log/?h=v15-dev or https://github.com/n8fr8/orbot/tree/v15-dev -- Nathan of Guardian nathan(a)guardianproject.info

4 4

Re: [tor-dev] Fwd: Orbot v15-alpha-3 with VPN and Meek!
by Nathan Freitas 14 Feb '15

14 Feb '15

On Sat, Feb 14, 2015, at 03:04 AM, CJ wrote: > > > On 14/02/15 08:58, Nathan Freitas wrote: > > > > > > ----- Original message ----- > > From: Nathan of Guardian <nathan(a)guardianproject.info> > > To: guardian-dev(a)lists.mayfirst.org > > Subject: Orbot v15-alpha-3 with VPN and Meek! > > Date: Sat, 14 Feb 2015 02:57:34 -0500 > > > > > > More progress on Orbot VPN support, and now, thanks to our new PLUTO > > library (https://github.com/guardianproject/pluto) support for Meek > > (https://trac.torproject.org/projects/tor/wiki/doc/meek) and soon Obfs4 > > as well. > > > > Currently you can use Meek or you can use VPN, but you can't use both > > together... still working on that, as I can't get Meek to talk to the > > passthrough HTTP proxy I use to allow socket connections out of the VPN > > filter. > > > > To use Meek, just enable the "Bridges" button on the home screen, > > without using any bridge config info, and it will default to using the > > Meek Azure instance. If you set the bridge line to 0 it will use Google, > > and 1 it will use Amazon, and 2 it will use Azure. > > > > The VPN mode is just as easy, just enable VPN using the homescreen > > toggle button, then start/restart Orbot. All apps on your phone should > > now be running through Tor. > > > > Remember, Bridges and VPN don't work at the same time, for now... but > > please test both features separately, and let me know how well they work > > for you. > > > > APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk > > SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk.asc > > > > Source: https://gitweb.torproject.org/n8fr8/orbot.git/log/?h=v15-dev or > > https://github.com/n8fr8/orbot/tree/v15-dev > > > Hello Nathan! > > Glad seeing this VPN part going further! I just have concerns regarding > my app compatibility (orwall): does orbot still opens ports on > localhost, and are they still the same, or shall I detect orbot version > and/or probe for opened ports? Everything is the same as usual. I don't think we can support both Orwall and VPN at the same time, so that will be another choice the user will have to make. The VPN doesn't fulfill the requirements of advanced users who want the level of protection provided by Orwall and what Mike Perry originally outlined. It is tricky to start on boot, there is no guarantee system services can't route around it, and it can be killed if Orbot crashes. Root and IPTables will still be required for that. VPN mode is really just for circumvention of app blocks by novice users. +n

1 0

Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
by Nathan Freitas 14 Feb '15

14 Feb '15

On Fri, Feb 13, 2015, at 07:45 PM, Yawning Angel wrote: > Yes, this means that if you run "kittensomgmewmew.onion" and are scared > of the NSA's persistent attempts to extract your hidden service key, > via ultrasonic laser beamed from their satellites, you could run your > tor instance entirely in a ram disk, and load the HS key manually each > time from a USB token you wear around your neck. A very practical use of this in the Orbot context, is that we can now store all HS identity data in an IOCipher encrypted volume, which the user can unlock with a strong passphrase when they want to start up their onionsites. Currently, all HS data is stored in the standard Tor data paths, only protected by the per-app user permissions on Android. This means the data can be accessed by rootkit capable malware apps and forensic extraction tools. With IOCipher, that would make that a great deal harder, and impossible if they were in a locked state (i.e. the key is not in memory). We are working on adding OnionShare-capabilities to Orbot, so this is well timed! +n

1 0

Authority Directory new IP
by SiNA Rabbani 13 Feb '15

13 Feb '15

Dear Tor, I am planning to change the IP address of Faravahar, it's basically a reconfiguration of the networking and how we are hosting it, to better stand future DDoS attacks. Here is the ticket for it: https://trac.torproject.org/projects/tor/ticket/14487 Should I also attach a patch for tor's source code? All the best, Sina "Be the change that you wish to see in the world." - Mahatma Gandhi

1 0

Multithreaded Crypto
by Nik 12 Feb '15

12 Feb '15

Hello, I'd like to try to help out and do some work on Tor's multithreaded crypto, specifically for incoming/outgoing cells. I've read through https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/Multithreade… as well as #1749 and #7572. I have a few questions for tor devs and people who've worked on/are working on the relevant bits of code: 1) Does the section "Phase 1: Cell crypto" in the Multithreaded crypto wiki page still reflect the current design and coding plans (along with the additions from the "Athena's notes" section)? 2) If so, approximately what stage of "Cell crypto: The plan" (on Multithreaded crypto wiki page) has development gotten to/is work currently being done on? I (briefly) looked around in master, and it looks like a crypting queue isn't being used yet. So if this is still the plan I guess I can assume that development is somewhere in phase 1? 3) Is there any other work/other branches I should take a look at? (i.e. in #7572, nickm commented "Andrea made some progress here", and I'm vaguely aware that there was a GSOC project last summer on multithreaded crypto, but it's not clear to me how far that effort got or how much of that code has made it into master.) 4) Is anyone currently working on this I should talk to? I know this can be a tricky thing to get right, so I just want to get a sense of where the best place to start might be and also avoid duplicating work someone else is doing/has already done. Thanks! All the best, Nik

1 0

Re: [tor-dev] A proposal to change hidden service terminology
by str4d 11 Feb '15

11 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Erik de Castro Lopo wrote: > A. Johnson wrote: > >> Several of us [0] working on hidden services have been talking >> about adopting better terminology. > > In general, I am in agreement with this, but I wonder if now might > be a good time to unify Tor terminology with other similar > technologies like I2P and Cjdns/Hyperboria. It is interesting that you raise this, because we at I2P have been thinking the same thing. We discussed the issue of I2P terminology at 31C3 and decided that after 12 years of Tor/I2P coexistence, Tor had the upper hand with regard to commonplace terminology. In our next release, we are changing most of our user-visible tunnel-related terms (I2P destination, tunnel, eepsite etc.) to instead use "Hidden services" in some way [0], to draw parallels to Tor hidden services - because as far as an end user is concerned, they do "pretty much" the same thing. And as far as we could tell, "hidden services" is now considered "too generic" for Tor [1], so it made sense to use it generically. Tags are now frozen for the 0.9.18 release, but we are still open to further discussion about terminology. > > I have heard someone (forget who) propose that 'Dark Web' be > dropped in favour of CipherSpace which could include all of these > privacy perserving protocols, leaving terms like "OnionSpace" for > Tor, "I2PSpace/EEPSpace" for I2P etc. I am certainly in favor of this kind of collaborative approach. It's hard enough already trying to make this stuff understandable to end users (usability and UX of the tools themselves aside), without having multiple kinda-similar-but-not tools trying to do so in different ways. A "united concept front" would benefit tools _and_ users. str4d [0] http://zzz.i2p/topics/1780-hidden-services-done-right [1] http://www.dailydot.com/technology/tor-crowdfunding-hidden-services/ > > Cheers, Erik > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU20J5AAoJEIA97kkaNHPnnzYQAI1iVeLcOcjVCR/hJ4nYq8ND DlyfENy0QYUtg9k85qIqoA2EEskUPDHDSRMqLZciQo2RgC7nFoNmgNjePUKXNtGA hLDodOjuEUcXQyA0+fl3v6sfzLxOc+E6sbLdnuV/wDgTuSPveVOgWi5eGUX2mb0/ DbYgMxp0kD0KghFPF1EPtj0S6sP1J/wwoFMJDhYm3no7qbWK1CqQvtfyxjkSXAmg EcdVWOqOUjA66ETNaMpQQVTiZ5MZVKM+2u5bDFDpwd4cEOuoy5bkiwy5gZLsIRot hB13as06kiWz6WAN8gsPqHF7t0JslHh9jSKIYRwuBf+e/NUtCGjGVVGf4YHwolgB 2AjuoeTAxzzBeNB6BvmSNw5h/oBt2S1fg0/QirCDrmpuQDKomD8+NI5EFatAiNkn 5RsbPrN/Clp+fJeW/Ypgh+ZUT2pO+Kps9fkgAs4u5QI6FnuCPvYGjsTil5a599KA 81FKzXOHNJ9L7IORmPymOZbN/Ba+upu6cznuB5KCRAt9q5QxAonx9Ry/oulC9kkF 9gacUY7Krglg5AUUlZA9dCesUftP8yeGhM52RreAkJTfK/rI94WK9YIaV/C3lbPb 233SthcQK3SoyRqR49B1ht3/4DgVah+6/K9TfQN7ZHjA0LizqUILqWuqO/5CLxNX uqkIyMePKodbzO8qr2TW =GTFn -----END PGP SIGNATURE-----

3 3

Let's come up with the roadmap for the future of OONI
by Arturo Filastò 11 Feb '15

11 Feb '15

Hello Oonitarians and Divisionists, I would love to have your feedback on what you believe to be the most important topics for the future of OONI. I have made a list of what I believe are all possible and interesting tasks to perform, but we can't do them all and for sure we can't do them all at once. For this reason it would be very useful if you could express a vote from 1-5: 1: Nah, this is boring and pointless 2: Not really super important, I would give priority to other stuff 3: Useful, I would do it 4: This would be awesome 5: Epic! Feel free to also expand these topics with questions and feedback (or new ones). At the end of the list I will give you a table to cast your vote. # Get daily OONI measurements from 50 countries This means focusing on getting a large and diverse reliable OONI userbase. It does not simply mean to get at least 1 measurement in 50 countries, but it means either establishing relationships with trusted parties in 50 countries, or expanding our userbase to a point where we have at least 1 measurement per day for every test per country (from the same network). Ways of achieving this are: * Rent a VPS in X number of countries * Running the adopt an ooniprobe program (see below for more details) * Establish an agreement with operators in 50 countries to host the probing infrastructure (as previously stated) # Develop OONI tests for censorship circumvention tools This involves devising a methodology for testing the reliability of censorship circumvention tools in various countries. It means testing censorship circumvention tool both open source and propertairy. A cursory list of the protocols/tools we could be interested includes, but is not limited to: * Tor * VPN * Web proxies (hidemyass, etc.) * SSH tunnel * Freegate * Psiphon * Ultrasurf * alkasir If you think we should be testing some other tools too, please add to this list. Useful resources: http://cyber.law.harvard.edu/publications/2011/2011_Circumvention_Tool_Eval… http://cyber.law.harvard.edu/publications/2010/Circumvention_Tool_Usage # Develop scheme for orchestrating ooni-probes This means coming up with a protocol that allows an OONI test developer to schedule a measurement to be run with a certain input they decide on a set of probes in country X. Obviously security considerations need to be taken into account and access will be in the initial stage only limited to a very restricted set of OONI developers that will be made public. # Implement data analytics and visualization for OONI tests We have a bunch of data and we would like to give meaning to it. This would involve writing tools for querying the data in the database and extract useful analytical information from it. Based on this data we can then start looking at historical OONI data and provide some sample visually supported reports. This is a list of tests we should develop analytics for: * HTTP requests * DNS Consistency * DNS Injection * TCP Connect * HTTP Invalid Request Line * HTTP Header Field Manipulation * Multi protocol port traceroute # Implement pub-sub system for ooni collectors Currently OONI collectors (the things you send your ooniprobe measurement results to) keep in sync thanks to a bunch of shell scripts and cronjobs. To have more real time data it would be useful to have a pub-sub mechanism that allows the pipeline to subscribe to all the collectors and the collectors will then publish the collected reports to it, as soon as they are submitted. This will allow the OONI data to go through the data pipeline much faster (instead of ~2 hours, perhaps just some minutes or even less potentially). # Reach production quality ooni rasperry-pi (beagle-board) images This involves implementing what is specified in the lepidopter specification: https://github.com/anadahz/lepidopter/blob/master/specification.md We should then provide scripts for building the image yourself or how to download and burn it to an SD card on Windows, OSX, Linux (with screenshots). As a bonus we could also offer shipping of pre-made raspberry pi images already burn to an SD card, similar to what is done with rasbpian images. # Promote and further develop OONI on mobile (Android, iOS) This involves improving the GUI of OONI on mobile and getting it into the Google Play store and the Apple App store. We should also work on making it easier for developers of existing iOS and Android apps to add internet measurement capabilities to their app by linking to libight. # Do research based on OONI This would involve doing some research on internet censorship based on OONI probe or on internet measurement in general and publishing them in peer reviewed venues. # Publish monthly reports about the status of internet censorship in a country This would be sort of like a monthly e-zine, where every month we analyse the status of internet censorship in a given country. It should be backed by OONI data, but the core of it should be an editorial type piece explaining the context of the country and how censorship is affecting them. I expect most of this work to be carried out by somebody that has a background in journalism and social sciences. # Run "adopt an ooni-probe" campaign This is basically a program where people make a donation to support getting somebody in an interesting country an ooniprobe or receiving an ooniprobe themselves. # Integration with other censorship measurement projects This means finding better ways of using data from other projects as part of OONI research or getting them to use our data. # Reaching out to communities inside of censored regions This means getting a better understanding of what "benefit" we can give to people that are running the tool. On this topic also see: https://trac.torproject.org/projects/tor/ticket/14760 # Redesign the website for ooni This means removing the horrible bootstrap basic template of the current website and restructuring it so people actually understand what OONI is and how it can be useful to them. # Hold an international internet censorship conference This means running an event where we invite a bunch of people that are active in the field of internet censorship and discuss ideas and possible collaborations. # Implement a GUI for ooniprobe This means picking up where we left off with the OONI web gui and finish implementing it. This could potentially also be useful for the orchestration task as we could implement access control on the HTTP API that the web interface consumes. Goal | Vote ---------------------------------- Get daily OONI measurements | from 50 countries | 0 ---------------------------------- Develop OONI tests for | censorship circumvention | tools | 0 ---------------------------------- Develop scheme for | orchestrating ooni-probes | 0 ---------------------------------- Implement data analytics | and visualization for OONI | tests | 0 ---------------------------------- Implement pub-sub system | for ooni collectors | 0 ---------------------------------- Reach production quality | ooni rasperry-pi | (beagle-board) images | 0 ---------------------------------- Promote and further | develop OONI on mobile | (Android, iOS) | 0 ---------------------------------- Publish monthly reports | about the status of | internet censorship in | a country | 0 ---------------------------------- Run "adopt an ooni-probe" | campaign | 0 ---------------------------------- Integration with other | censorship measurement | projects | 0 ---------------------------------- Reaching out to communities| inside of censored regions | 0 ---------------------------------- Redesign the website for | ooni | 0 ---------------------------------- Hold an international | internet censorship | conference | 0 ---------------------------------- Implement a GUI for | ooniprobes | 0 ---------------------------------- Do research based on | OONI | 0 ---------------------------------- Thanks for taking the time to go through this long email, you can as always find us on IRC #OONI irc.oftc.net. Have fun! ~ Arturo

3 2

A proposal to change hidden service terminology
by A. Johnson 11 Feb '15

11 Feb '15

Hello all, Several of us [0] working on hidden services have been talking about adopting better terminology. Some of the problems with current terms are 1. '''Hidden''' and '''Dark''' have a negative connotations. 2. '''Hidden-service website''' is too long; '''hidden site''' is too vague. 3. '''.onion''' (read "dot onion") is hard to say and not very descriptive. 4. There is no general term for the set of available hidden services. 5. The term '''encrypted service''' is too general. This term refers to a setup (still needing development) in which Tor is required to connect to a service, but the service location is not hidden. Even without server anonymity, this setup can provide enforced client anonymity, secure name resolution, censorship circumvention, and end-to-end-encryption. Making the server location known can allow for improved performance (by shorter circuits) and security (by enabling location-aware path selection by the client). We’ve come up with the following suggestions for better terms, which we’d like to offer up for discussion: 1. '''onion service''' should be preferred to refer to what is now called a "hidden service". If other flavors of onion services develop in the future, this term could refer to all of them, with more specific terms being used when it is necessary to make the distinction. 2. '''onionsite''' should be preferred to refer to a website (i.e. an HTTP service serving up HTML) available as an onion service. This can be extended to other specific types of services, such as '''onion chatroom''', '''onion storage''', '''onion cloud service''', etc. 3. '''onion address''' should be preferred to refer specifically to the xyz.onion address itself. 4. '''onionspace''' should be used to refer to the set of available onion services. For example, you can say “my site is in onionspace” instead of “my site is in the Dark Web”. 5. '''onion namespace''' should be used to refer to the set of onion addresses currently available or used "recently" (context-dependent). We couldn’t decide on the best names for alternative onion service setups, because they don’t exist yet! But, we have some ideas about how these things might be named: 1. Some names for a setup in which the onion service location is known but still must be connected to via the Tor protocol: * '''Tor-required service''', '''TRS''' for short * '''Direct onion service''', '''direct service''' for short 2. Some names to specify that the onion service is hidden, if that becomes necessary: * '''Protected onion service''', '''protected service''' for short * '''Tor-protected service''', '''TPS''' for short 3. Some names to specify that a client connects to an onion service non-anonymously: * '''Client-direct access''' * '''tor2web mode''' We’re maintaining an evolving wikipage with the above suggestions [1]. Some of us are already beginning to use the suggested terminology, to see how it works out. One nice goal might be for Tor to choose the new terms that it likes (if any) and use them in the rollout of next-gen onion services [2]. So we’re bringing up this subject now to a larger segment of the Tor community. Thoughts? Best, Aaron [0] Including David Goulet, Rob Jansen, George Kadianakis, Karsten Loesing, and Paul Syverson [1] https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Termino… [2] https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t…

6 7