anonymize Tub IDs when using Tahoe-LAFS with anonymity net like Tor or I2p #2384
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#2384
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I believe it was Leif Ryge who first pointed this out...
We really need to randomize the client ID when using an anonymity network like Tor or I2p.
This ticket is definitely related to #517
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517
This ticket also seems to be a sub-ticket of #1010
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1010
in so far as we can turn this client ID randomization on and off with a configuration option.
anonymize client IDs when using Tahoe-LAFS with anonymity net like Tor or I2pto anonymize Tub IDs when using Tahoe-LAFS with anonymity net like Tor or I2pBrian pointed out in Nuts & Bolts today that #510 would solve this.
Replying to zooko:
Or maybe it was Daira who pointed that out.
Replying to [zooko]comment:3:
It was. (More precisely, that an HTTP-based protocol wouldn't have this specific problem with client tub IDs, although that isn't the only problem involved in client anonymisation.)
Current status: client connections to storage servers use ephemeral Tubs (thanks to #2759), so storage servers won't see tub-id correlations between subsequent boots of a single client.
The IntroducerClient, though, uses a static tub (with key stored in
NODEDIR/private/node.pem
) for all connections. So the Introducer can correlate connections across client reboots.Do folks think we can close this ticket as is, or should we use an ephemeral Tub for the introducer client too?
(note that when Accounting happens, clients will get a persistent !Ed25519 public key, and they'll sign their storage-server messages with it. But I think we can just declare that when
anonymous=true
, these keys are disabled, or regenerated at each boot, and you don't get to participate in any accounting-related tasks. Maybe we can add apseudonymous=true
flag which will allow persistent client pubkeys, but still enforce the other safety restrictions. In that world, servers could tell which clients were which, but that "identity" is still unlinked to the client's real IP address)In today's devchat, we decided to document the TubID linkages that clients currently reveal (introducer client + storage server, and multiple connections within a single client lifetime for everything else), and then close this ticket. We'll add a new ticket (with milestone=
undecided
) for either addressing the remaining linkages, or WONTFIXing them.#2828 added for addressing/accepting the remaining linkages.
In 80acd56/trunk: