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

Delete this message

Reply to this message
Author: anonym
Date:  
To: The Tails public development discussion list
Subject: Re: [Tails-dev] RFC: persistent Tor state
On 05/21/2015 05:38 PM, sajolida wrote:
> 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.


I wouldn't call this a mitigation, but at least it's something.

> This might then become a new argument to fix #7165
> [NetworkManager autoconnects to persistent wireless networks in Wheezy].


Definitely.

> 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 :)


If there's no SSID, like on wired connections, we just set a default
SSID of the empty string or whatever.

> 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"?


We do not really have any solid reasoning here. We need to make a
worst-case analysis for how N affects the probability of picking
compromised guards in a Tor network where C out of G guards are
compromised (and in the control of our local attacker).

Thanks for your input!

Cheers!