Author: intrigeri Date: To: The Tails public development discussion list CC: tor-talk, desktops, The Tails public development discussion list, whonix-devel Subject: Re: [Tails-dev] Persistent Tor start in Tails vs location aware Tor
entry guards (LATEG)
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.
> 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 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)?
