Diffstat (limited to 'wiki/src/blueprint/tails_server.mdwn')
1 files changed, 16 insertions, 0 deletions
diff --git a/wiki/src/blueprint/tails_server.mdwn b/wiki/src/blueprint/tails_server.mdwn
index 3c8034f..8d6b2ff 100644
@@ -146,3 +146,19 @@ Prints the value of the provided option.
#### set-option OPTION VALUE
Sets the provided option to the provided value.
+# Obligatory Client Authentication
+My current proposal is that, until we can use a Tor version with the [next generation onion services](https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt) in Tails, Tails Server should enforce the use of client authentication, i.e. it will not be shown as an option to the user and will always be turned on. We could add a somehow hidden option (maybe a command line option) to disable client authentication, so that users who know about the risk still have a way to use Tails Server without client authentication.
+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.
+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/)).
+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)