Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#2980 closed enhancement (wontfix)

feature request: better privacy for node operators

Reported by: tagnaq Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay
Cc: tagnaq@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The goal of this requested feature is to minimize the identifying bits of a Tor node
and to reduce the negative privacy effects for a Tor node operator running a non-exit at home.
It is related to this post:
https://lists.torproject.org/pipermail/tor-talk/2011-April/020195.html

I'll describe the features in form of manpage entries:

NodePrivacy 0|1
This option affects relaying nodes only and makes only sense on hosts with dynamic IP address.
If set to 1 a minimal and standardized descriptor will be published (ORPort: 9001, DirPort: 9030, Nickname: "Unnamed", ContactInfo: "" (empty), exit policy: reject *:*, tor version: "" (empty), MaxAdvertisedBandwidth not honored, ...). Before a new descriptor is published, long term keys are reseted if an IP change is detected and StateResetInterval is 0.
If StateResetInterval is non-zero long term keys will only be resetted if the interval is expired AND an IP change has been detected.
NOTE: EVEN WITH THIS OPTION ENABLED YOU WILL PROBABLY BE TRACEABLE - IT JUST GETS SLIGHTLY HARDER.
(Default: 0)

) Example: If a node is down for lets say a month and comes back online it might even be a usfull feature for nodes with static IP addresses
(the fact that a node has a static IP address is not necessarily a public fact)

StateResetInterval N d|w
Specifies the time interval for which long term key material will not be resetted - only relevant if NodePrivacy is set to 1.
(Default: 0)

Depending on how many Tor nodes in a certain AS are running with NodePrivacy enabled with rawly same StateResetInterval and BW NodePrivacy will actually improve privacy or not.

Side effect of this feature: The Tor network will probably have less nodes having the 'guard' and 'stable' flag set and statistics of relays based on their published tor version might see empty version strings.

Child Tickets

Change History (8)

comment:1 Changed 7 years ago by Sebastian

I don't like the proposal, tbh. I don't buy that this will make relays who are on dynip connections less traceable, because they will make a new key and disappear with the old key at roughly the same time. Not reporting version is actively harmful, because Tor clients use that to decide what to use a given relay for. This design isn't great (especially because it prohibits alternative implementations of Tor relays, but while we have it we can't introduce an option like that).

I also worry that a bunch of people set that option without actually understanding what it does, thus harming our metrics-related goals without a real need. I don't see a real threat model that this change could detect against. Please motivate the change more, so that I might change my mind :)

comment:2 Changed 7 years ago by rransom

Not advertising relays' maximum permitted bandwidth will ruin Tor clients' load balancing without actually hiding the relays' bandwidth from an active attacker.

comment:3 Changed 7 years ago by tagnaq

Cc: tagnaq@… added

Replying to Sebastian:

I don't like the proposal, tbh. I don't buy that this will make relays who are on dynip connections less traceable, because they will make a new key and disappear with the old key at roughly the same time.

This is true unless there are enough other nodes on your network "colliding" with your IP+key renew. For networks with lease times >12h and a low number of tor nodes this good collision is rather unlikely, but there are ISPs enforcing IP renews every <12h. So this feature is becoming more useful in the future with more nodes on the same network.

Not reporting version is actively harmful, because Tor clients use that to decide what to use a given relay for. This design isn't great (especially because it prohibits alternative implementations of Tor relays, but while we have it we can't introduce an option like that).

Yes I was not so sure about tor version and BW - lets drop them from the common list of settings.

  • ORPort: 9001,
  • DirPort: 9030
  • Nickname: "Unnamed"
  • ContactInfo: ""
  • exit policy: reject *:*


I also worry that a bunch of people set that option without actually understanding what it does, thus harming our metrics-related goals without a real need.

So the config option should probably not contain 'Privacy' in the name - which is too desireable to have :) ...so probably 'CommonDescriptor' reads less desirable ;)

I don't see a real threat model that this change could detect against.

Do you disagree that this feature (rekeying ones in a while + common descriptor) would make it harder to link tor nodes to there past ip addresses and reduce the privacy impact of running a tor node at home?

comment:4 in reply to:  1 ; Changed 7 years ago by tagnaq

Replying to Sebastian:

I don't like the proposal, tbh. I don't buy that this will make relays who are on dynip connections less traceable, because they will make a new key and disappear with the old key at roughly the same time.

In the most useful use case of this feature - the Tor relay running on a notebook of an often traveling person. This feature would make it impossible to use the tor node fingerprint to track the persons movements.

comment:5 in reply to:  4 ; Changed 7 years ago by rransom

Resolution: wontfix
Status: newclosed

Replying to tagnaq:

In the most useful use case of this feature - the Tor relay running on a notebook of an often traveling person. This feature would make it impossible to use the tor node fingerprint to track the persons movements.

I fixed #988 in order to make tracking users who try to run a bridge on their laptop somewhat harder. (That bug was actually filed because a malicious relay (or someone who can monitor a relay's Internet connection) could have passively collected bridge identity keys and fingerprints, and then used the bridges' fingerprints to obtain their descriptors from the bridge authority, not because of any concern for bridge operators' location privacy.)

But people who run a public relay need to understand that they are publishing their IP address, and other information needed for their relay to function as part of the Tor network, in a widely available, publicly archived list.

I also think this option would put people at greater risk of unintentionally running a public relay. I found out that I was inadvertently running an exit node because I saw my Tor instance's nickname on a TorStatus site; if I hadn't recognized it, I could still be running an exit node, and I would be vulnerable to serious attacks ranging from DoS (by causing my computer to connect to a ShadowServer honeypot, and thus leading my ISP to turn off my Internet connection) to imprisonment (by framing me for a crime).

I'm closing this ticket as ‘wontfix’, because there is no chance that we would accept this option for public relays -- it provides at most a tiny benefit to relay operators, at a large cost to the Tor network. If you are willing to implement some of these features for bridge relays only, and you can show that your implementation will only affect bridges, feel free to post your patches on a new ticket.

comment:6 in reply to:  5 Changed 7 years ago by tagnaq

Replying to rransom:

But people who run a public relay need to understand that they are publishing their IP address, and other information needed for their relay to function as part of the Tor network, in a widely available, publicly archived list.

This is not about tor node operators only. Everyone using the same IP (NAT) as a non-exit node is affected by this issue.

it provides at most a tiny benefit to relay operators, at a large cost to the Tor network.

As written above this is not about relay operators only.

I think a tor node operator (and everyone who is forced to use his IP) should be the one to decide whether this is an issue for them or not.

comment:7 Changed 6 years ago by nickm

Keywords: tor-relay added

comment:8 Changed 6 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.