[pt-br] Update translation bits.

[tails-test.git] / wiki / src / blueprint / server_edition.mdwn

[[!meta title="Tails server: Self-hosted services behind Tails-powered Tor hidden services"]]

[[!toc levels=3]]

Use cases
=========

Secretly work on a document
---------------------------

John, Jane and Miranda would like to secretly work on a
document.

Possible solutions follow.

### 1. Centrally hosted Etherpad

Tails can be used to access a centrally hosted Etherpad.

Their physical location and identities should be properly concealed
but the document itself can be intercepted by the server operators.

They would like to have other means than blind trust to keep the
secrecy.

### 2. OpenPGP-encrypted messages in a shared mailbox or a drop.io space

Tails can be used to pass GnuPG-encrypted messages through a shared
mailbox or a drop.io space.

This sounds like a pretty good answer but they are under a lot of
pressure and are likely to make mistakes. Leaking a clear-text version
to the service provider would be fairly easy under stress.

### 3. Gobby and SFTP servers behind a Tails-powered Tor hidden service

Anyone amongst John, Jane and Miranda could use Tails to host Gobby
and SFTP servers behind a Tor hidden service. Others would also use
Tails to reach them.

Keeping such servers at hand, on a live system, behind an hidden
service is likely to prevent erroneous disclosure.

The vision
==========

Let's talk about group collaboration, communication and data sharing
infrastructure, such as chat servers, wikis, or file repositories.

Hosting such data and infrastructure *in the cloud* generally implies
to trust the service providers not to disclose content, usage or users
location information to third-parties. Hence, there are many threat
models in which cloud hosting is not suitable.

Tor partly answers the *users location* part; this is great, but
*content* is left unprotected.

There are two main ways to protect such content: either to encrypt it
client-side (*security by design*), or to avoid putting it into
untrusted hands in the first place.

Cloud solutions that offer security by design are rare and generally
not mature yet. The *Tails server* project is about exploring the
other side of the alternative: avoiding to put private data into
untrusted hands in the first place.

This is made possible thanks to Tor hidden services, that allow users
to offer location-hidden services, and make self-hosting possible in
many threat models. Self-hosting has its own lot of problems, however,
particularly in contexts where the physical security of the hosting
place is not assured. Combining Tor hidden services with Tails'
amnesia property and limited support for persistent encrypted data
allows to protect content, to a great degree, even in such contexts.

This vision aims at making it easy for end-users to implement
solutions described above and based on Tor hidden services hosted on a
Tails system.

Tails server should be able to run common services like a web
server, a Jabber daemon, wiki, file repository, etc.

Data and configuration for services would be stored on an encrypted
flash media. Targeted hardware to run "Tails server" would be an
old laptop with broken hard-disk, battery, screen or keyboard;
something quite common these days.

In short, setting up a new Tails server would be done by:

1. Alice plugs a USB stick into a running desktop Tails system.
2. Alice uses a GUI to easily configure the needed services.
3. Alice unplugs the USB stick, that now contains encrypted services
   configuration and data storage space.
4. Alice plugs that USB stick (and possibly a Tails Live CD) into the
   old laptop that was dedicated to run Tails server.
5. Once booted, Alice enters the encryption passphrase either directly
   using the keyboard or through a web interface listening on the
   local network.
6. Then, Bob can use the configured services once he gets a hold on
   the hidden service address. (The *petname system for Tor hidden
   services* project would be very complementary to this one, by
   the way.)

Tails server should content itself with hardware that is a bit old
(such as a PIII-450 laptop with 256MB of RAM) and/or half broken (e.g.
non-functional hard-disk, screen or keyboard).

Roadmap
=======

This project [was accepted](https://www.torproject.org/getinvolved/volunteer.html.en#tailsServer)
for GSoC 2012, and worked a bit before the student dropped the ball.
You can check the proposal [here](https://dustri.org/pub/tails_server.pdf)

The challenges behind this project are:
  * Design and write the services configuration GUI [keywords: edit configuration files, upgrade between major Debian versions, debconf, Config::Model, augeas].
  * How to create the hidden service key? [keywords: Vidalia, control protocol].
  * Adapt the Tails boot process to allow switching to "server mode" when appropriate.
  * Add support, to the Tails persistence setup process, for asking an encryption passphrase without X, and possibly with a broken keyboard and/or screen [keywords: local network, SSL/TLS?, certificate?].

Timeline
========

Turn an USB stick into an USB Tails server stick
------------------------------------------------
The user should be able to create a Tails server USB stick, which should boot in Tails server mode by default, and no more to Tails. During this milestone, there are no or only small differences between Tails and Tails server except that the system is aware that he is booting into Tails server.

Unlocking persistence without a GUI
---------------------------------------
The end user should be able to unlock and boot a Tails server USB stick without any GUI.

Remote administration
---------------------
The user should be able to have a secure shell (SSH) on the machine, to do administration tasks without a physical access to the Tails server, or a GUI. Please note that this shell is not a Tor hidden service for now.

Remove unnecessary/irrelevant things from boot process
------------------------------------------------------
Tails server should not spawn a full-featured desktop anymore: the goal of this iteration is to remove as much irrelevant services as possible (e.g GNOME, Xorg, ...) in order to reduce boot-time and system resources. The only way the user have to do administration's related tasks is to use SSH.

Setup Tor hidden services
-------------------------
This part is a little bit unclear for now.

Setup and start a gobby service
-------------------------------
This is the first Tor hidden service implementation and it will allow the user to run a Gobby service from the Tails server. This step does not involve any configuration of the service, only the setup; no user interactions are involved during this milestone, since there is no configuration involved.

Basic configuration management
------------------------------
The user should be able to edit the configuration of the Gobby service during the creation of the Tails server USB stick; like using a password, changing the service's name,


Requirement/Deliverable
=======================
  * Clean design and documentation
  * Everything hosted through Tor hidden services
  * Amnesic system
  * Switch to Tails server on boot
  * Support for persistence to save preferences/configurations.
  * GUI configuration tool


Implementation
==============

Switch to "server mode" at boot time
------------------------------------

What follows is a preliminary implementation plan that allows us to
ship ISO images that are able to boot in "server mode" or in "desktop
mode".

This should be refined to integrate better into the standard Debian
Live boot process. E.g. the standard persistence support should be
used to iterate over block devices, find the one that contains the
server configuration and decrypt it.

When starting a server we *must* have the server configuration present
on a USB drive during boot, so we can simply check for its presence
with a hook in early init. If present, then we enter server mode and
don't start X, network manager, etc., otherwise we just boot Tails
in the normal fashion.

Elaborating on my suggestion above, what I describe below will have the
server mode init sequence logic happily contained in two init scripts
that are specifically made for this purpose, so no other init scripts
will be bloated with conditionals or altered in any way:

As I said, we introduce two new init scripts:

1. `server-check`, which is run as early as possible (i.e. as
   soon as the filesystem is up and we can mount USB drives)
2. `server-mode`, which is run once the network is up

`server-check` will loop through all USB drives (even the one Tails
is running from if running from USB) and for each `$X` of them, in
turn:

1. check for the presence of a storage media containing a Tails-server configuration,
using  GPT partition's label.
2. if the check failed continue to loop
3. if the check succeeds, ask the passphrase and activate persistance storage (see below)

So, if no drive contained a server configuration `server-check` exits and boot continues as usual. If a Tails-server configuration was encountered, the file `/var/lib/live/tails-server-mode` is created.

`server-mode` will check if the server state file exists and contains
a valid path to a file, namely the server configuration. If the check
fails, boot continues as usual, otherwise the server-mode service
will, in chronological order, take care of:

1. receiving the configuration encryption password some how
2. decrypting $(cat /var/lib/live/tails-server-mode)
3. starting the ssh daemon, http server, wiki software, etc.
   using their decrypted configuration files
4. updating torrc with the decrypted configuration
5. sending tor a SIGHUP so it will reload its configuration and
   finally start the hidden service(s)

If any of the above fails an appropriate error message should be shown
to the user. Possibly we could start X and network manager (i.e. like
in a normal boot) show the error there and then let the user try to
sort out the error, e.g. by mounting the server configuration and
editing the faulty config file, or by using the GUI you talked about
to create a completely new server configuration.

Boot process
------------
The default for a given Tails server installation is to boot in Tails server
mode.

### Check configuration presence
When Tails boots, it will at some point
check for the presence of a storage media containing a Tails server
configuration, using GPT partition's label. So, the boot continues in
Tails server mode, if not, boot continues for normal Tails, the user
warned, and prompted about what should be done, either reboot in
Tails, or recheck for a preference USB stick.

### Asking the passphrase and activating persistence storage
(this part is not chronological)

#### Advertising on the LAN
Tails-server needs to advertise his presence and location on the LAN.
The less worth manner is to use avahi/zeroconf. Since they can be more than on Tails-server on
the same LAN, I think that the user may choose the named advertised by avahi for his server; since the LAN is an untrusted network, using the .onion hidden service name for this purpose is not an option.

#### LAN
Since the most common setup is a LAN with a modem/router
provided by the ISP, they contains at least one untrusted machine. So MITM attacks are likely to happen; this is why we need to be able to authenticate the server. Doing so require that the client carry some informations about the server (certificates, and/or ssh keys).

#### Dropbear
A possible solution would be to take advantage of the cryptsetup/dropbear integration in debian to boot encrypted (but /boot) system. The client would log using ssh into Tails-
server, and enter the passphrase using a custom shell which is
roughly a passphrase-prompt. To make this solution more user
friendly, a lightweight GUI on the client side that would basically launch avahi, scan the network, show available Tails-server (since they can be many), ask for a passphrase for the selected
Tails-server and finally stop avahi could be easily developed.

#### Webpage
Another way would be to use a simple webpage (php/apache are overkill : a simple CGI would be fine) to get the passphrase. This approach allows a simple client-side GUI in that starts/stops
avahi, and scans and lists Tails-servers (they can be severals).
When clicked, iceweasel simply opens the selected server's webpage. This should even be doable in fairly small shell script using zenity. this solution has the advantage of being platform-
independent.

#### Authentication
Self signed certificates do more harms than good, since they scare the user because of the browser warning. But, because Tails-server can only be created from Tails, generated
certificates fingerprint could be stored in a ~/.Tails-server folder
on the client : Any certificates found there would be added to
iceweasel on as soon as Tails has opened the persistent volume
and found this preset. Client's Ssh public key must be stored too,
and written in the /.ssh/known hoss of the server.

### ervices configuration with preseed
Once Tails server is booted, it will preseed the Debian system's debconf database with the settings
obtained from the Tails server configuration files.

### Services installation
Service's packages will be installed by APT (to
take advantage of dependencies resolutions, upgrades, ..). Since the
persistence code bind-mounting the cache directory onto the location
where APT normally looks, there's nothing more to tell APT about.


### Services configuration patches
As previously said, not every packages
will be configurable in a suitable manner. We will have to patch some
software's configurations after their setup.

### Services startup
Since not every services supports autostart, this is the step during which
they will be started. Moreover, some service configurations where patch


Installation process of services softwares
------------------------------------------
Two solutions are available: either install all server softwares in the
default Tails, or install them dynamically from the USB stick during
the boot of Tails server. Even if the second solution is better (because
it will not unnecessary bloat Tails), the first one is much more simpler to
implement, and since it's not a critical (or even important) feature, it can
be implemented later, outside the scope of the GSoC.

Configuration management
------------------------
Tails-server will often require custom "default" configuration for a bunch
of softwares due to its nature. Service configuration requires a nice way to
handle the configuration files in order to avoid a complete disparate mess.
In an ideal world, every services configurations should be handled by deb-
conf (and not by some ugly monkey patching). Doing so will keep Tails-
server upgrade-proof, since configuration file's format are not frozen, and
may evolve between updates, using debconf will make this transparent.
### Upstream (Debian)
The best way is to ask to the related package maintainers to
add in debconf options that we want to access from debconf to configure
the package if they are not already present. Since the freeze of Wheezy (the
next Debian stable) is planed for June, I don't think there will be time for
this to happen any time soon. Most likely the debconf approach way will
be postponed to the Wheezy + 1 Debian release(probably in 3 years).

### Patch on boot
If we can't get the options we want from the package maintainers, the
most appropriate solution is to patch configurations files on bootime. Such
patches can be augeas scripts, Config::Model somethings, or whatever seems
robust enough.

### Other options
Some cases don't fit well into the "debconf or patch on boot" alternative.
These situations would have to solved on a case-per-case basis.

On Tails update
---------------
When a new version of Tails is available, the server admin should be warned
about this. Tails already implements this mechanism in it's GUI, but as Tails
server cannot rely on GUI in its normal operation, this must be redesigned.
As a placeholder, the admin should be invited to subscribe to the amnesia-
news mailing-list.

Tails server configuration GUI
------------------------------
The purpose of this GUI would
be to properly setup a persistence USB key for tail-server, with services
configuration, authentication means, ...

Time synchronization
--------------------

As contributed by adrelanos on tails-dev
(<50293C63.2040807@riseup.net>), servers are supposed to run over
longer periods without rebooting, days or weeks so Tails's current
implementation with tails_htp is not sufficient for Tails Server.

adrelanos suggests:

> My recommendation is to run htpdate periodically, perhaps every
> hour. Time exact minute should be randomized to avoid creating
> a network fingerprint.
> 
> Given what you already implemented with `tails_htp`, running
> `tails_htp` frequently probable won't be hard. As I need it for aos,
> I am planing to add a script to /etc/cron.daily, it will run another
> script in background to avoid blocking anachron during the sleep
> delay. The other script will simply pick a number between 0 and 3600
> from /dev/random, sleep for the delay and then restart the
> htpdate service.

Resources
---------

### pairing

* [git-annex' pairing design](http://git-annex.branchable.com/design/assistant/pairing/)

### Vidalia's hidden services support

In 0.3.x: was removed, should become a plugin someday: it's a [GSoC
project](https://github.com/feroze/vidalia-plugins/tree/hiddenservice)
by Feroze Naina <ferozenaina@gmail.com>; early in August 2012, is
"awaiting being merged into the vidalia-plugins repo".

In 0.2.x: works mostly well but we need to wait for
[[!tor_bug 2579]] to be fixed.

### The Incognito implementation

The old Incognito actually has a very rudimentary support for hidden
services which was setup in a similar way. However, it is limited to
hosting static html pages using lighthttpd, but the script used might
be worth looking at:

- http://www.browseanonymouslyanywhere.com/incognito/uploadfiles/docs.html#hidden
- https://svn.torproject.org/svn/incognito/trunk/root_overlay/etc/init.d/hidden-service

### Anonymous Web Application Framework

https://piratenpad.de/p/AnonymousWebApplicationFramework


Simplified edition of this project
=========

### Would it be easier to implement a simpler version of this project?

Would a simplified version of this project be easier to implement, and could it act as a precursor to the full blown implementation?

* No remote administration. Less remote access is usually more secure. Many users will not want to use their desktop machines SSH client for administration because it is not amnesic
* No zeroconf, zeroconf is insecure and advertises too many details on the local LAN
* The basics of this project is to tell the tor configuraiton file there is a hidden service listening on a certain local port (e.g. apache) and to run that server software inside tails. Vidalia has a GUI for this too. This is a simpler version of the project, and would work to provide a hidden service from within a tails livecd
* Would it be preferred to have the screenlock software installed as well so the server can run with a locked screen. Would need to have the ALT+F1,F2 etc gettys disabled or password protected.
* A simpler version that does provide a hidden service, but only the bare minimum other features, would not prevent all the other useful features specified in this document from being implemented at a later date, and may get more people interested in using it
* Some of the features in this document make more work to get them running, but would actually decrease security and anonymity (advertising on LAN, administering from a LAN PC)