Project

General

Profile

Feature #11732

Feature #5462: Persistence preset: Tor state

Make guard nodes stable across reboot

Added by segfault over 2 years ago. Updated 9 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
08/26/2016
Due date:
% Done:

0%

QA Check:
Feature Branch:
Type of work:
Research

Description

Tor uses entry guards [1] to make some deanonymization attacks harder. We currently don't have this in Tails, because it would allow location tracking of Tails users by observing which guard nodes are used, which would be a severe regression and render the MAC randomization feature useless.

See [2] for thoughts on the location tracking problem and an attempt to find a compromise between protecting against location tracking and deanonymization attacks.

[1] https://www.torproject.org/docs/faq#EntryGuards
[2] https://tails.boum.org/blueprint/persistent_Tor_state/


Related issues

Related to Tails - Feature #11884: Document using Tor bridges to work around missing entry guards Confirmed 10/20/2016

History

#1 Updated by sajolida over 2 years ago

  • Related to Feature #11884: Document using Tor bridges to work around missing entry guards added

#2 Updated by segfault over 2 years ago

This is especially important for Tails Server, because Onion Service deanonymization is trivial when the attacker controls the entry guard.

Maybe we could use a separate Tor process with persistent entry guards for Tails Server? And add a warning about location tracking when using Tails Server in different locations.

#3 Updated by segfault over 2 years ago

Note that the current plan is to enforce client authentication in Tails Server, which protects from the deanonymazation by the entry guard. But this limits the use cases for Tails Server a lot (it requires all users to either use Tails, which would come with a Tails Server client app, or enter the authentication cookie in the torrc themselves via the command line).

#4 Updated by intrigeri over 2 years ago

Maybe we could use a separate Tor process with persistent entry guards for Tails Server?

I don't have this part of our codebase fully in mind, and I may very well be wrong, but I suspect that synchronizing the config to that new Tor service instance, and adjusting the semantics of "Tor is ready" to take it into account, will be a big burden and will make an already insanely complex setup even harder to wrap one's mind around and debug. So I'd rather see other solutions looked into first, personally.

#5 Updated by intrigeri over 2 years ago

  • Blueprint set to https://tails.boum.org/blueprint/persistent_Tor_state/

#6 Updated by u 9 months ago

@segfault: is this still something you think we should work on?

#7 Updated by intrigeri 9 months ago

Yes, it's critical. That's the part of #5462 that's on our 2018 roadmap.

Also available in: Atom PDF