This repository has been archived by the owner on Oct 23, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 15
/
Copy pathspec.txt
179 lines (131 loc) · 7.3 KB
/
spec.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
Title: APAF: Anonymous Python Application Framework
Author: Arturo Filastò, Michele Orrù
Created: 16 March 2012
# 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).
# 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 an 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.
# Build System
The core component of APAF is it's build system. Application developers will
specify a manifest file that details all of the application dependencies,
what kind of priviledges are required for execution, description and all
metadata associated with the application.
The primary focus of the build system will be Windows and Mac OS X. Build for
linux distributions will be done with native tools (i.e. dpkg for
Debian/Ubuntu, rpm for Red Hat, etc.).
APAF compiles all the dependencies for all the target systems.
At bare mininum the dependencies that will be bundled with an APAF based
application are:
* the Python interpreter (cpython)
* Tor
* Python modules reqiured by system libraries (i.e. Twisted, zope.interface, etc.)
The build system must be configurable and extensible. It should allow easy bundling of
third party applications such as p7zip, gpg, etc.
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
In future:
- Android: MyApplication.apk
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.
# What services that APAF expose to the network?
APAF will expose two kinds of service:
1) The administration web application for the user
2) The applications to be run as Tor Hidden Services
These two network services must only be listening on localhost and the
administration interface should require authentication. The password for
accessing the administration interface will be randomly generated at first
boot and shown to the user. It can later be changed from the admin panel.
# 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 the APAF UI will provice a wizard for bootstrapping the setup of the
Tor Hidden Service.
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
* Start and stop the Hidden Service
* 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)
# Web Applications
Apaf comes with two example applciations:
- zinniablog, which demonstrates how to integrate a django application within
apaf;
- staticfileserver, which serves to the client static files
# APAF Utility library
APAF will provide a python library to allow the application developer to
interact with the currently running APAF system. This allows a certain
application to:
* Understand what it's .onion address is
* Check the current status of the running Tor daemon
* Make TCP connections over Tor
# Security
## Threat model
What security properties should APAF provide? What attacks (or classes of
attacks) should APAF prevent or resist?
-- see wiki page.
### Tor Hidden Service disclosure
All of the security and anonymity properties of Tor Hidden Services must be
preserved. It must not be possible to understand who is running a certain Tor
Hidden Service and it must not be possible to determine that a certain Tor
user is running a Tor Hidden Service remotely.
Inside of this evaluation we do not include attacks that are piggy backed on
top of other attack vectors. This means for example that if an attacker uses
an XSS to understand that a certain user is listening on a certain port
therefore they are running APAF is not protected in this threat model.
### Application
The default applications shipped with APAF shall protect again remote
unauthorized access even through other attack vectors. This means that it
should not be possible to exploit an XSS to gain control over the running
APAF system.
The application developer should also take care into protecting his
application from fingerprintability. This means that, for example, the
default HTTP server will atempt to behave and mimic the default HTTP server
configured with Tor HS (Apache or thttpd).
### Outbound connection Torification
The applications shipped by default with APAF must provide full torification
of all outbound connection. The application developer is highly encouraged to
torify all their outgoing traffic, but this will not be enforced by the
application rather from their good sense.
### Inbound traffic
The inbound traffic shall allow the user to set if they wish to expose their
service also through dark net -> to -> internet service (i.e. tor2web in the
case of HTTP).
### Securization and sandboxing (for future)
APAF shall provide out of the box sandboxing for the running applications
based on their operating system. It will use for example sandbox-exec on OSX,
when available AppArmor or SeLinux and the windows equivalent of this. The
running application will drop privilidged and run inside of a chrooted
environment.
# 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 AWAF built application