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

Wed Feb 10 00:42:22 CET 2016

[quoting you in full since this mail was eaten by the whonix-devel list
for some reason even though I manually allowed it]

intrigeri:
> Hi,
> 
> [can you please decide what mailing-list this discussion should happen
> on, and then we can stop cross-posting over 4 mailing-list?]
> 
> Patrick Schleizer wrote (02 Jan 2016 22:36:13 GMT) :
>> But I think location aware Tor entry guards (LATEG) are wrong headed.
>> The topic of LATEG is so difficult to explain to the user, that as you
>> plan, you cannot add it the the UI. Perhaps buried under an advanced
>> setting, but that's not worth so much. So it cannot be manual by
>> default. Only automatic.
> 
> I agree.
> 
>> Which brings me to the issue.
> 
>> There is a reason, why Tor picks a Tor entry guard and sticks to it. By
>> changing it more often than Tor would do, you are subverting the reason
>> for using Tor entry guards in the first place. In a sense, you are to a
>> small degree thereby becoming a Tor developer, and modifying Tor's relay
>> choosing algorithm.
> 
> I think I see what you mean, and indeed it's the kind of things about
> which my self-confidence is pretty low, and I'd personally rather
> avoid fiddling with things I don't understand.
> 
> But the thing is: by using random guards every time Tails starts, we
> are _already_ making the very same kind of decisions. Only, we are
> making it very badly, and this has been going on for too many years
> already.
> 
> Let's face it: as distro integrators, in the current state of things,
> we have to make a decision to compensate for the fact that Tor's guard
> selection wasn't designed with our threat model in mind.
> Keeping things as-is would be a decision. Using fully persistent entry
> guards (not location aware), like Tor Browser users get currently,
> would be another decision. We cannot escape it, so we're trying to
> make this decision in a way that's much better for the vast majority
> of Tails users.

The simplest answers to give it are "same as Tor default", "same as
Debian system Tor" and/or "same as TBB". Since you can install Debian
and Tor on USB or TBB and USB, then be on travel, The Tor Project has
decided to keep entry guards across geographical location. The would
imho be the best [as closest to TPO] solution that any Tor focused
distribution can do.

>> I wonder, if the whole LATEG thing would not be much better implemented
>> in Tor itself. If so, then any (further) research of the entry guard
>> topic would still apply to Tails, and not to Tor only.
> 
> With my (lazy by design) distro integrator's hat, I can only agree:
> the more work is done by little-t-tor, the less I have to deal with
> myself, and the more is shared cross-distro. Yay.
> 
> However, taking a step back, I'm not sure it makes a whole lot of
> sense: to be location-aware, tor would have to gain knowledge about
> new concepts, and interface with OS services, that it can currently
> happily ignore so far; add to this that tor is multi-platform;
> I expect it's not an easy problem to deal with at this specific place,
> but again: if someone solves it, I certainly won't complain :)
> 
>> The documentation advice for advanced users caring about AdvGoalTracking
>> could be to use obfuscated [private] bridges and to alternate
>> them per travel location.
> 
> Right, I think it's important that people who what more control can
> get it this way, and IIRC our current best proposal does not prevent
> anyone from doing this.
> 
>> Or perhaps you might be able to explain in tor-launcher /
>> anon-connection-wizard [1] [2] [3] the LATEG / AdvGoalTracking issue.
> 
> If the configuration GUI has good facilities to document a broad and
> complex problem, yay, bringing the doc closer to the software is
> probably a winning strategy.

>>> [...] By adding the SSID, we prevent attackers from being able to
>>> spoof only the MAC address of the router to reuse a given Tor state;
>>> they also have to spoof the SSID which is visible to the user and might
>>> be detected as malicious. [...]
> 
>> I find it unlikely, that users might judge an often changing SSID
>> malicious. FreeWifi832458252823523 vs FreeWifi358235892435. How many
>> users are going to remember that? I would guess, they would just click
>> through whatever hoops required to make the WiFi connect again.

I'll rephrase this below.

> I have no time/energy to think seriouly about it now, and I've been
> postponing my reply for a month due to this, so I'll try to be
> pragmatic: I'm adding this as a FIXME on our blueprint, and will come
> back to it later.
> 
> 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.

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'.

*

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.

To make the attack better, the adversary could decide to tear it down.
The user would likely recognize this as networking would fail. Then the
user would likely look into Network Manager scan results and click the
next FreeWifi[somelongnumberhere].

To have location aware code, you need to gather location data. WiFi
names, signal strength, MAC addresses are not suited to conclude the
current location as this information can be influenced by adversaries.
You perhaps would have to gather such data from GPS. [I don't know if
there are attacks against it that are related here.] But I guess most
devices where Tails is running nowadays don't have GPS.

So you would have to ask the user for its location. But usability wise
such questions are awful.

Cheers,
Patrick