tahoe-lafs/trac-2024-07-25

address remaining anonymity-violating linkages #2828

New issue

Open

opened 2016-09-13 09:22:23 +00:00 by warner · 0 comments

warner commented

2016-09-13 09:22:23 +00:00

Owner

storage servers can recognize multiple connections from the same not-yet-rebooted client
when Accounting is enabled, clients may present the same long-term pubkey to all servers (we might disable accounting when private-mode is turned on)
by watching storage-index access patterns, servers can probably recognize specific clients, or identify files that are shared by multiple clients (e.g. if the server observes a long delay, then fetches of SI A, then B, then C, then A is probably a rootcap, B is a subdirectory, and C is a file)
a malicious Introducer could deliver different (tagged) server announcements to each client, then watch the resulting connections, to correlate the client's main TubID with the server requests it then makes
client+server nodes use the same Tub for outbound introducer connections and inbound storage connections, which might reveal something (the TubID is included in the published announcement, so it's not clear that we can hide anything here)

This ticket is about either addressing these linkages, or declaring them unfixable (so WONTFIXing this ticket is acceptable).

As described in #2384, even with Tor and ephemeral client->server Tubs, there are some remaining ways that servers (or the Introducer) can link the various actions of a single client, to build up a "client identifier". * storage servers can recognize multiple connections from the same not-yet-rebooted client * when Accounting is enabled, clients may present the same long-term pubkey to all servers (we might disable accounting when private-mode is turned on) * by watching storage-index access patterns, servers can probably recognize specific clients, or identify files that are shared by multiple clients (e.g. if the server observes a long delay, then fetches of SI A, then B, then C, then A is probably a rootcap, B is a subdirectory, and C is a file) * a malicious Introducer could deliver different (tagged) server announcements to each client, then watch the resulting connections, to correlate the client's main TubID with the server requests it then makes * client+server nodes use the same Tub for outbound introducer connections and inbound storage connections, which might reveal something (the TubID is included in the published announcement, so it's not clear that we can hide anything here) This ticket is about either addressing these linkages, or declaring them unfixable (so WONTFIXing this ticket is acceptable).