For the recent work towards Tails Server, see tails server.
This is the blueprint created during the 2012 GSoC Tails Server project, which was discontinued early. It had a different vision of the Tails Server, with it being a special version of Tails which would run on a machine dedicated for the Tails Server.
###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.
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:
- Alice plugs a USB stick into a running desktop Tails system.
- Alice uses a GUI to easily configure the needed services.
- Alice unplugs the USB stick, that now contains encrypted services configuration and data storage space.
- Alice plugs that USB stick (and possibly a Tails Live CD) into the old laptop that was dedicated to run Tails server.
- Once booted, Alice enters the encryption passphrase either directly using the keyboard or through a web interface listening on the local network.
- 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).
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?].
###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,
- 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
###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:
server-check, which is run as early as possible (i.e. as soon as the filesystem is up and we can mount USB drives)
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
- check for the presence of a storage media containing a Tails-server configuration, using GPT partition's label.
- if the check failed continue to loop
- 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:
- receiving the configuration encryption password some how
- decrypting $(cat /var/lib/live/tails-server-mode)
- starting the ssh daemon, http server, wiki software, etc. using their decrypted configuration files
- updating torrc with the decrypted configuration
- 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.
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).
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.
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.
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.
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.
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.
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.
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, ...
As contributed by adrelanos on tails-dev (50293C63.email@example.com), 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.
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_htpfrequently 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.
Vidalia's hidden services support
In 0.2.x: works mostly well but we need to wait for bug #2579 on Tor Project's Trac 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
##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)