tails_server.md

-[[!tag archived]]
 
-[[!meta title="Tails Server"]]
 
-[[!toc levels=3]]
+---
+title: Tails Server
+---
+
+
+
+[[_TOC_]]
+
 
 # Vision
 
@@ -17,7 +22,7 @@ Such services are immensely helpful for working together in groups over distance
 * It works behind NATs and firewalls
 * It limits attack surface
 
-Tails Server should be usable via both a graphical user interface (GUI) and a command line interface (CLI). The interfaces would be used from within a running Tails session (in contrast to the design in the [Legacy Blueprint](https://tails.boum.org/blueprint/server_edition/). The CLI solution would make it easy to administrate Tails Server remotely via SSH.
+Tails Server should be usable via both a graphical user interface (GUI) and a command line interface (CLI). The interfaces would be used from within a running Tails session (in contrast to the design in the [Legacy Blueprint](https://tails.boum.org/server_edition/). The CLI solution would make it easy to administrate Tails Server remotely via SSH.
 Both interfaces should make it easy for the user to install and configure services, and automatically configure the services for the use in Tails. It should be a generic solution which makes it easy to add many different services.
 
 In addition to service specific options, the user should be able to choose:
@@ -179,12 +184,13 @@ My current proposal is that, until we can use a Tor version with the [next gener
 
 The reasoning for this is that users running onion services in Tails currently face an increased risk of deanonymization. In the default Tor configuration, the first Tor node that the Tor client connects to stays the same for a longer time, currently 60 days. This node is called the entry guard. The reasoning is to reduce the risk of using a bad entry node, because the entry guard is the only node in the Tor network that knows the real IP address of the Tor user. An attacker controlling the entry guard gains important information about the Tor user, which can lead to deanonymization.
 
-Tails currently does not [persist the Tor state](https://tails.boum.org/blueprint/persistent_Tor_state/), which means that Tor chooses a new entry guard after each system boot. Thus Tails users have a much higher risk to use a bad entry guard at some point, which is bad enough in itself. But when hosting onion services in Tails, this is even worse, because it is a lot easier for a bad entry guard to deanonymize onion services than normal Tor clients. For example, if an attacker knows the onion address of an onion service A and control a Tor node which is used as an entry guard, they can just block all traffic on the entry guard and try to connect to A. If A is unreachable only while they block the traffic at their Tor node, they know that it is A who is using their Tor node as an entry guard, so they know the IP address of A.
+Tails currently does not [persist the Tor state](https://tails.boum.org/persistent_Tor_state/), which means that Tor chooses a new entry guard after each system boot. Thus Tails users have a much higher risk to use a bad entry guard at some point, which is bad enough in itself. But when hosting onion services in Tails, this is even worse, because it is a lot easier for a bad entry guard to deanonymize onion services than normal Tor clients. For example, if an attacker knows the onion address of an onion service A and control a Tor node which is used as an entry guard, they can just block all traffic on the entry guard and try to connect to A. If A is unreachable only while they block the traffic at their Tor node, they know that it is A who is using their Tor node as an entry guard, so they know the IP address of A.
 
 This attack requires the attacker to know the onion address of the onion service they want to deanonymize. Unfortunately, the current implementation allows attackers controlling a directory server responsible for an onion service to learn that service's onion address. This will be fixed in the next generation onion services. So once we can use the next generation onion services in Tails, it will be sufficient for Tails Server users to keep their onion address secret and only share it with users they trust. I think this will be good enough to make the client authentication optional and display a prominent warning about keeping the onion address secret in Tails Server. 
 
 The Tor stable release 0.3.1 with next generation onion services is [planned vaguely for August 2017](https://lists.torproject.org/pipermail/tor-dev/2016-December/011725.html). Since we don't have a release schedule for Tails Server yet, we might consider waiting for Tor 0.3.1 before releasing Tails Server.
 
-In the long term, we should come up with a compromise between the location tracking risk of persistent entry guards and the risk of deanonymization by a bad entry guard (see [persistent_Tor_state](https://tails.boum.org/blueprint/persistent_Tor_state/)).
+In the long term, we should come up with a compromise between the location tracking risk of persistent entry guards and the risk of deanonymization by a bad entry guard (see [persistent_Tor_state](https://tails.boum.org/persistent_Tor_state/)).
 
 XXX: Explain how this greatly reduces the use cases in which Tails Server is useful (all clients have to use Tails; onion addresses can't be publicly advertised)
+