Re: [tor-talk] [Secure Desktops] [Tails-dev] Persistent Tor start in Tails vs location aware Tor entry guards (LATEG)

[intrigeri <intrigeri@xxxxxxxx>]

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?

> 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/

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.

Cheers,
-- 
intrigeri
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk