Feature #11732

Make entry guard persistent across reboot

Added by segfault 2016-08-26 07:30:44 . Updated 2020-02-23 20:14:58 .

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

0%

Feature Branch:
Type of work:
Research
Blueprint:

https://tails.boum.org/blueprint/persistent_Tor_state/

Starter:
Affected tool:
Deliverable for:

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/

Subtasks

Related issues

Related to Tails - Feature #11884: Document using Tor bridges to work around missing entry guards Confirmed 2016-10-20
Has duplicate Tails - Feature #17487: Persist Entry Guards Duplicate

History

#1 Updated by sajolida 2016-11-01 12:43:27

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

#2 Updated by segfault 2016-11-05 00:16:46

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 2016-11-05 00:23:12

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 2016-11-05 09:20:49

> 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 2016-12-05 15:58:01

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

#6 Updated by Anonymous 2018-08-17 15:21:48

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

#7 Updated by intrigeri 2018-08-17 16:40:52

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

#8 Updated by sajolida 2020-02-23 20:14:59

  • Subject changed from Make guard nodes stable across reboot to Make entry guard persistent across reboot

#9 Updated by sajolida 2020-02-23 20:15:11