> From: sajolida <sajolida@???>
>
> Actually, now that we have MAC spoofing enabled by default, this
> auto-connection only leaks the fact that "someone" is connecting to this
> network but shouldn't contain any personally identifying information.
> What other threat are you worried about? Apart from the edge case of WPA
> Enterprise with unique user credentials.
I agree with flapflap that this isn’t necessarily an edge case. An adversary can learn what SSID is available at your residence, then advertise the same SSID at other places you might visit. Your machine will connect (or attempt to connect) to the bogus access points, thus revealing your presence.
>>> It would be interesting to design the system so that before it
>>> takes actions that are known to create a risk of leaking
>>> information about the user, the user gets a prompt. For example,
>>> add dialogs that say Join known Wi-Fi network <SSID>? or Install
>>> apps AAA, BBB, and CCC? or Connect to printer <NAME>?
>
> Regarding installing apps AAA, note that this is only known by the Tor
> exit node and the Debian mirror serving those packages at the exit side
> of Tor, so there's no way of knowing who is doing that and where they
> are. So I don't think that this is really problematic.
The problem with installing apps, and especially with running them, is that there are few limits to what they can reveal on the LAN (assuming they can avoid the default policy of forcing all traffic onto Tor, which is an assumption we should make) or to sites on the other end of the Tor network. Dotfiles create a similar (but weaker) problem by influencing the operation of apps.
Ultimately, any repeatable pattern of LAN activity going into the Tor network can be recognizable, even if it can’t be read—this is what’s known as traffic analysis. If an adversary learns that your machine generates six packets of specific lengths in a specific order each time it connects to Tor, and other machines don’t, you are no longer anonymous.
In fact, I’m pretty sure a rogue app could send messages to an adversary on the LAN through this mechanism even if it can’t avoid having its traffic go into the Tor network.
> Regarding the printer example, I don't have enough technical insight to
> know if having a printer configured in persistence implies actively
> probing it on start. Possibly, and if so then your workaround would be
> worth exploring. That would be worth being asked on tails-dev.
By connecting to a printer without first scanning to see what printers are available, a machine reveals that it expected the printer to be present. Which suggests that maybe we could always scan for printers at startup even if we don’t really care about the results; that would be a more anonymous behavior.
> I already sent an answer on that a few minutes ago. For some reason this
> answer of yours Peter broke the thread and I didn't see it. I'm trying
> to bring it back to the original thread. Let's try to stick to it (Peter
> do "Reply" on this thread).
I initially subscribed in Digest mode, and I didn’t have a way of embedding a specific References: field in my reply headers. I’ve switched to individual messages, so that will work properly going forward.
> We're currently heading to considering LAN as untrusted by default and
> enforcing this quite strongly. See
> https://mailman.boum.org/pipermail/tails-dev/2014-November/007314.html <https://mailman.boum.org/pipermail/tails-dev/2014-November/007314.html>
Ah, yes, I had read that when browsing the dev list archives after they came back online, and it seemed like that discussion was moving in the right direction. But as others said in that thread, there are good practical reasons to give the user the choice to trust the local network. We should just discourage it as much as possible. As you said, people may be inclined to trust their own networks too much.
. png
