anonymize Tub IDs when using Tahoe-LAFS with anonymity net like Tor or I2p #2384

Closed
opened 2015-02-10 18:23:24 +00:00 by dawuud · 7 comments
dawuud commented 2015-02-10 18:23:24 +00:00
Owner

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
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517

This ticket also seems to be a sub-ticket of
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.

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.
tahoe-lafs added the
unknown
normal
defect
1.10.0
labels 2015-02-10 18:23:24 +00:00
tahoe-lafs added this to the undecided milestone 2015-02-10 18:23:24 +00:00
zooko changed title from anonymize client IDs when using Tahoe-LAFS with anonymity net like Tor or I2p to anonymize Tub IDs when using Tahoe-LAFS with anonymity net like Tor or I2p 2015-02-10 18:26:35 +00:00

Brian pointed out in Nuts & Bolts today that would solve this.

Brian pointed out in Nuts & Bolts today that #510 would solve this.

Replying to zooko:

Brian pointed out in Nuts & Bolts today that would solve this.

Or maybe it was Daira who pointed that out.

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/2384#issuecomment-96777): > Brian pointed out in Nuts & Bolts today that #510 would solve this. Or maybe it was Daira who pointed that out.
daira commented 2015-02-11 16:25:14 +00:00
Author
Owner

Replying to [zooko]comment:3:

Replying to zooko:

Brian pointed out in Nuts & Bolts today that would solve this.

Or maybe it was Daira who pointed that out.

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

Replying to [zooko]comment:3: > Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/2384#issuecomment-96777): > > Brian pointed out in Nuts & Bolts today that #510 would solve this. > > Or maybe it was Daira who pointed that out. 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 ), 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 a pseudonymous=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)

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 a `pseudonymous=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)
warner added
code-network
and removed
unknown
labels 2016-08-29 23:30:47 +00:00
warner modified the milestone from undecided to 1.12.0 2016-08-29 23:30:47 +00:00

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.

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.
warner self-assigned this 2016-09-06 19:29:16 +00:00

added for addressing/accepting the remaining linkages.

#2828 added for addressing/accepting the remaining linkages.
Brian Warner <warner@lothar.com> commented 2016-09-13 09:23:12 +00:00
Author
Owner

In 80acd56/trunk:

docs: describe known linkability

closes ticket:2384
In [80acd56/trunk](/tahoe-lafs/trac-2024-07-25/commit/80acd565e2f49717450a3281139fe80f9c855f7e): ``` docs: describe known linkability closes ticket:2384 ```
tahoe-lafs added the
fixed
label 2016-09-13 09:23:12 +00:00
Brian Warner <warner@lothar.com> closed this issue 2016-09-13 09:23:12 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#2384
No description provided.