[Whonix-devel] [Tails-dev] [Secure Desktops] Persistent Tor start in Tails vs location aware Tor entry guards (LATEG)

[Patrick Schleizer]

I mistyped. Here is the correct version.

day 1

1) Tails user regularly goes to physical place A that provide [free] WiFi.
2) The name of the wifi is FreeWifi832458252823523 with MAC address "A".
The user uses the regular way to set up a WiFi connection. Network
Manager etc.
3) Now, Tails would remember FreeWifi832458252823523 and assign entry
guard A.

day 2

3) Tails user goes to the same physical place A that provide [free] WiFi.
2) The name of the wifi has changed to FreeWifi358235892435 with mac
address "B". The user uses the regular way to set up a WiFi connection.
Network Manager etc.
3) Now, Tails would remember FreeWifi358235892435 and assign entry guard B.

intrigeri:
> Hi,
> 
> Patrick Schleizer wrote (09 Feb 2016 23:42:22 GMT) :
>> intrigeri:
>>> [can you please decide what mailing-list this discussion should happen
>>> on, and then we can stop cross-posting over 4 mailing-list?]
> 
> This still holds.
> 
>>> I'm not sure I understand the problem you mean to raise, though.
>>> Can you please elaborate what problem you see if users do exactly this
>>> ("click through whatever hoops required to make the WiFi connect
>>> again", which I agree is very likely)?
> 
>> day 1
> 
>> 1) Tails user regularly goes to physical place A that provide [free] WiFi.
>> 2) The name of the wifi is FreeWifi832458252823523 with MAC address "A".
>> The user uses the regular way to set up a WiFi connection. Network
>> Manager etc.
>> 3) Now, Tails would remember FreeWifi832458252823523 and assign entry
>> guard A.
> 
>> day 2
> 
>> 3) Tails user goes to the same physical place A that provide [free] WiFi.
>> 2) The name of the wifi has changed to FreeWifi358235892435 with mac
>> address "B". The user uses the regular way to set up a WiFi connection.
>> Network Manager etc.
>> 3) Now, Tails would remember FreeWifi358235892435 and assign entry guard A.
> 
> I don't understand why we would pick Entry Guard A in the last step on
> day 2, can you please explain?

I mistyped. Entry guard B.

>> This is the behavior I expect from most users. And this is what I meant
>> by 'users will click through whatever hoops required to make the WiFi
>> connect again'.
> 
> Fully agreed!

>> The entry guard selection would now be influenced by by the provider of
>> the [free] WiFi. And I think such an adversary capability is something
>> as we agree that is to be avoided.
> 
> Right, it's something we want to limit. anonym and I have been working
> a bit more on it, and have reverted the addition of the ESSID in the
> data we hash, found another attack, thought a bit about potential
> defenses, and discussed it a bit more. See the "First iteration"
> section on our blueprint for details:
> 
> https://tails.boum.org/blueprint/persistent_Tor_state/

You quoted me! Glad that I was heard! :)

> In the current state of things we're undecided whether our current
> design is good enough to be worth shipping, or not. We'll probably ask
> someone (probably Isis) for help evaluating it and/or designing
> something better.

Or perhaps consider asking the tor-talk (-dev) mailing list in order to
get more input.

Cheers,
Patrick