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

Delete this message

Reply to this message
Autor: sajolida
Data:  
Dla: The Tails public development discussion list
Temat: Re: [Tails-dev] RFC: persistent Tor state
intrigeri:
> 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/
>
> 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.


I've read the blueprint and really much like it. I'm a bit scared about
the drawbacks but I wonder how we could do better...

In one the drawback you describe an attacker faking the MAC address of
the home router of the user as a confirmation attack to identify her
somewhere else. You are supposing that the attacker spoofs only the MAC
address of the AP. Could it be some kind of mitigation to also require
the attacker to spoof the SSID? Because then, if Tails doesn't
auto-connect to that AP, the user might detect that there is an AP
faking her home SSID. This might then become a new argument to fix #7165
[NetworkManager autoconnects to persistent wireless networks in Wheezy].

So would it then make sense to hash:

hash(Tails device secret, N bits of gateway MAC, SSID)

Of course, I'm simplifying here to Wi-Fi only as there is no notion of
SSID with wired connections. But you know, wire is deprecated :)

On another topic, I found the shortcut to the 6 number a bit too quick.
How do you go from "between 500 and 2000 Tor relays" and "N=6 → 64
possible Tor states"?

I was interested to see a "do not ask me again" message. We've also
considered something similar while working on the bootstrapping process.
For example, to suggest setting up persistence on first boot. Could it
be worth building something generic? Without prompting the user too much
with such messages I'm sure we can find other useful use cases for them
(maybe the release notes after an upgrade for example).

--
sajolida