Tor Hidden Services are great, though their impact is grossly limited by the fact that they are not at all easy to deploy. Systems such as Tor2web allow people that decide to publish anonymously to be reachable by anybody not using a Tor client.
For dealing with the usability aspect of Tor Hidden Services, this GSoC I am going to be mentoring APAF: Anonymous Python Application Framework. The goal is to give easy to use tools for people to do self publishing.
This is a basic description of the project:
1. Overview Tor Hidden Services are underused compared to their potential, the goal of APAF is to provide an easy system to allow network related python application developers to build their software in a way that it runs as a Tor Hidden Service (Tor HS). The framework will allow developers to easily build .exe, .app, statically linked linux binaries that contain the python interpreter and the Tor daemon. This will allow the end user to easily start running that service on their machine, by simply downloading a package. This is similar to what is done with the Tor Browser Bundle (TBB).
2. Motivation One of the reasons for which Tor HS are not used that much is that there is no simple way for an application developer to ship their application with a Tor binary and automatically configure a Tor HS. This leads to users not being able to easily run Tor Hidden Services on their desktop machines limiting the diffusion of HSs. An example use case is a person that wishes to run a temporary chat server on their home machine. With APAF a chat server developer could package such a python application and the end user will be able to run it by downloading a package and executing it.
3. What is built? APAF compiles all the dependencies for all the target systems. The software that will come bundled with it are: * the Python interpreter (cpython bundled with PyInstaller: http://www.pyinstaller.org/) * Tor * The desired python dependecies (computed with PyInstaller) The build system must be configurable and extensible. It should allow easy bundling of third party applications such as p7zip, gpg, etc as APAF modules, in order to let the project grow with new functionalities.
The output of the build process will be: - Win32: MyApplication.exe - OSX: MyApplication.app (inside an Application.dmg container) - Linux: Deb build or statically linked binary The buildsystem should download the latest release of Tor for the appropriate platform and extract the required files into the build structure, in order to be packaged within the application. Note: Another possibility is that it could build Tor from source for the desired target platforms, but this may require some additional effort.
4. What happens when I start APAF? When APAF starts the user running it is presented with a splash screen that displays the startup progress. The image in the splash screen should be customizable by the application developer. Another option would be to start the system browser and point it to http://127.0.0.1:<APAF_port>/ and display the bootstrap process inside of the bundled web based UI. At first launch APAF will show a startup splash screen with a progress bar describing application startup event informations, optionally displaying an image. Then the system browser will be started to let the user access APAF UI, that will provide a wizard for bootstrapping the setup of the Tor Hidden Service. If the APAF application is already running by clicking on it, it will just start the browser to open directly the APAF UI. By default APAF will come with a web application that is used for administering and checking on the status of the running Tor HS. It should provide functionality the following functionality: * Check the current status of the Tor HS (it's hostname and port mapping) * Start and stop tor Hidden Service * API to add/remove new Tor Hidden service mapping * Select from the list of bundled applications the ones to run * Test it's reachability from the Tor network (by doing a request over Tor to it's .onion address) * Configure Tor (User Interface to edit torrc) * Close Awaf
5. Web Applications One of the first applications that will be used as an example for APAF will be a simple python web application. The application will simply serve to the client static files. The basic scaffolding that this web application provides should allow developers to build their own web application based on this example. The application will be written using TornadoWeb (http://www.tornadoweb.org/).
6. Security Features Outbound Connection Torrification --------------------------------- The framework must provide support to automatically torify all or specific outbound connection. The entire python application framework (Tornadoweb) should be forbidden to make any outbound connections directly, it should not leak out of the Tor network. Inbound Connection (Tor Hidden Service) --------------------------------------- APAF will expose to the Tor network the configured Tor Hidden Service running the bundled server software. The user will be able to properly configure their HS and choose if to allow connections from tor2web (in the case of a web application) or not. Misc. ---- Ideally the application should come with security enhancements such as sandboxing and hardening of the system to minimize anonymity leaks and security vulnerability exploitability.
7. Documentation APAF must provide detailed documentation on: - how to setup the build environment (eventually on multiple operating systems) - how to customize your own enviroment for your own anonymous web application - any specific documentation on particular procedures and/or internal structure - user manual for running an APAF built application
Specific to Google Summer of Code the student will complete the following:
For GSoC the student is expected to create the build system capable of building a simple web application that serves static files. It should also include a web UI for a wizard setup, checking the status of the HS and configuring it.
I believe this project has some common goals with the work TAILS wants to do on the "TAILS server edition" [1].
I would be very interested in having feedback on this topic to manage to properly set the scope of the tasks to be done during GSoC.
maker is interested in working on this project and we have been discussing it with him in the past days.
- Art.
[1] tails.boum.org/todo/server_edition/
Hi,
Arturo Filastò wrote (23 Mar 2012 22:45:39 GMT) :
I believe this project has some common goals with the work TAILS wants to do on the "TAILS server edition" [1].
Sure. There's probably some work that can be shared. It's unclear to me what part of it yet, but we'll see.
It's striking how different those projects are, but not as much as the fact we independently thought of proposing them for GSoC the very same year. I think it confirms "something like this" is needed, and I'm glad of seeing this happen.
Tails server and APAF share something important: they don't exist yet. There are a few big differences between Tails server and APAF, though. Let me mention some of those, and we'll see what we can learn from this. At least I'm sure comparing Tails server with APAF will help clarify what Tails server would be :)
Amnesia vs. post-mortem analysis of the equipment -- Tails server is likely to be based on Tails (no kidding), inheriting much, if not all, of its threat model and specification, including taking radical measures to avoid writing anything to local storage media unless the user explicitly asks for it. I did not see any such thing in the APAF description. Is this part of the APAF threat model? I must say I am impressed with how far something like the TBB goes to satisfy this requirement at the application level. At some level, things get out of control of most applications anyway (hints: swap, usage of various OS functionality that may, or may not, write stuff to disk), but even if we disregard that level, I'm not sure how a webapp framework for a generic language such as Python could try to satisfy this requirement as well as the TBB.
Target hardware and usage model -- As far as I understand it, APAF is aimed at running on the Desktop (that is on a desktop or laptop computer that's running a full-blown desktop environment such as GNOME). We expect most of the services provided by Tails server to run 24/7 in cupboards, garages and basements. I don't expect users to keep their desktop or laptop running and online 24/7. This is one of the reasons why Tails server should be fully functional on boxes people do not want, or cannot, use as Desktop computers anymore, e.g. because of hardware being half-broken or not powerful enough to run a modern Desktop environment plus server software.
Applications -- Tails server is meant to run any existing application we add and maintain support for, building on existing blocks such as Gobby and a few others. As far as I understand it, APAF is a framework to write, and maintain, a set of brand new applications that would be bound to this specific environment -- in other words, people not interested in Tor are unlikely to ever contribute to such an application. I find the APAF approach to be very ambitious.
Future -- Tails server would be a practical contribution to the FreedomBox project, that should explore some of the FreedomBox aspects: 1. In a way that's immediately useful to lots of people. 2. In a way that _practically_ attacks some of the FreedomBox technical challenges (e.g. configuration management on the long term, upgrade management, unlocking encrypted storage at boot time on a potentially headless machine). 3. With a specific threat model in mind, that's not shared by all people who {are, should be, are supposed to be, could, might} be working on the FreedomBox project. Showing them deployed, working code and systems will be much better an advocacy for anonymity, storage encryption, and location hiding, than trying to explain them why they should write support for all of this themselves. Ideally, the purpose of Tails server should be taken over by the FreedomBox some day, and the process that leads to Tails server should help the FreedomBox to actually exist some day. Sometimes, it's great to start a project while knowing right from the beginning it could very well become obsoleted by something even greater that will be maintained by, or with, entirely different people.
Tails server should be able to run APAF applications, right?
Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
-
Arturo Filastò -
intrigeri