Re: [Tails-dev] RFC: persistent Tor state

Delete this message

Reply to this message
Author: Alan
Date:  
To: tails-dev
Subject: Re: [Tails-dev] RFC: persistent Tor state
Hi,

> anonym and I have made great progress on this front, and we would like
> feedback from you folks regarding the state of our current reasoning
> and preferred design:
>
> https://labs.riseup.net/code/issues/5462
> https://tails.boum.org/blueprint/persistent_Tor_state/
>

I've read through this. Congrats for this!

> In particular, the "Drawbacks of persistent Tor state" section is
> important, and because of it the proposed design will require some
> project-wide decision:
>
> https://tails.boum.org/blueprint/persistent_Tor_state/#drawbacks
>
> => added to the summit's agenda, but we can certainly start discussing
> it earlier.
>

The 1st drawback: "If the attacker records that someone has been
using a given Entry Guard at a given location in the past, and then
someone uses the same Entry Guard at the same location, then there are
chances that it's the same person who is back to that location." looks
quite concerning to me, as I believe this kind of data can easily be
recorded automatically and used afterwards:

- what about a delay after which not to reuse an old location? Would
that be a major problem for mitigating the "attacks against anonymity
via stable Entry Guard(s)"?
- what about prompting the user, when they reconnect to an old location
after having connected to other, if they want to reuse the data or
not? It's not very clear to me the implications of not reusing these
data however.

The 2nd drawback "If the attacker records what guard a Tails user is
using at home, and then configures the routers, in other chosen places, to use
the same MAC address. Then, the attacker can confirm whether the user
is visiting those places" looks less serious to me as:

- it's a more active and targetted attack;
- it looks likely to me that if the attacker takes the energy to access
the routers, they could do other confirmation attacks based on the
traffic and browsing habits of the user

To mitigate this 2nd drawback, I see no other way than to ask the user
where they connects from (eg with a codename by location), which seems
complicated to explain.

Hope it helps