Opened 7 years ago

Last modified 2 years ago

#5903 new enhancement

Restore ExcludeEntryNodes feature

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay, needs-proposal needs-design
Cc: Actual Points:
Parent ID: Points: 10
Reviewer: Sponsor:

Description

Seems that ExcludeEntryNodes configuration option was removed at some point (atleast 0.2.3.15-dev's "verify-config" rejects it).

It however would be nice to have it to avoid the "adversary can monitor entry and exit nodes" scenario which is very real in countries with few relays (which can be legally compelled to do such a thing) while still using the country's exitnodes (I don't have a problem with my traffic making a trip around the world and exiting to public Internet from the relay that my neighbour runs, I do however have a problem with my traffic entering the Tor network from the high-bandwidth relay with a Guard flag that my *other* neighbour, who happens to be an associate of the first neighbour, is running).

Child Tickets

Change History (11)

comment:1 Changed 7 years ago by nickm

Milestone: Tor: unspecified

comment:2 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:3 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:4 Changed 6 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.5.x-final

comment:5 Changed 6 years ago by nickm

Keywords: needs-proposal added

The tricky parts to get right will be:

  • Making sure it applies to entry nodes on the codepath where we pick guards at random from all guards, AND on the codepath where we pick guards from configured EntryNodes, AND on the codepath where directory guards are turned off entirely.
  • Deciding whether it applies to anonymous connections only, or to direct directory requests as well.
  • Figuring out what should happen when
  • Figuring out what should happen when the user has no consensus networkstatus document, and they have excluded every authority and directory source that they know about.
  • Figuring out what should happen if a specified bridge is excluded.
  • Figuring out what should happen if a bridge is excluded by fingerprint, but we don't learn its fingerprint until after connecting to it.
  • Refactoring the code and/or adding mocking stubs to the code sufficient for us to have rigorous testing for all of the above.

comment:6 Changed 6 years ago by nickm

See also #6525, which is not quite the same, but which should be designed in tandem.

comment:7 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:8 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:9 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:10 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:11 Changed 2 years ago by nickm

Keywords: needs-design added
Points: 10
Severity: Normal
Note: See TracTickets for help on using tickets.