Opened 2 years ago

Last modified 2 weeks ago

#21864 new defect

Support Bridges setting MyFamily to include Relays

Reported by: isis Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: intro, 15min, tor-relay, tor-bridge, is-this-safe
Cc: phw Actual Points:
Parent ID: Points: 0.5
Reviewer: Sponsor:

Description

In src/or/config.c:

  if (options->MyFamily && options->BridgeRelay) {
    log_warn(LD_CONFIG, "Listing a family for a bridge relay is not "
             "supported: it can reveal bridge fingerprints to censors. "
             "You should also make sure you aren't listing this bridge's "
             "fingerprint in any other MyFamily.");
  }

In src/or/router.c, function router_build_fresh_descriptor:

  if (options->MyFamily && ! options->BridgeRelay) {
    smartlist_t *family;
  […]

I propose instead that we:

1) Warn bridge operators not to include other bridges in MyFamily, but let them know that including relays is fine. We should continue to warn them not to list any bridge in the MyFamily of a public relay.
2) Allow bridges to specify MyFamily.

The reasoning for this is that NoiseTor would like to run high-capacity default bridges for Tor Browser, but they are nervous about simultaneously running exits without being able to direct people not to use both.

Child Tickets

Change History (10)

comment:1 Changed 2 years ago by isis

Keywords: intro added; easy removed

comment:2 Changed 2 years ago by cypherpunks

also relevant for torservers (they run %20 of bridges and ~%10 exit capacity)
https://lists.torproject.org/pipermail/tor-relays/2017-March/012186.html

comment:3 Changed 2 years ago by cypherpunks

Some more thoughts:

  • Since MyFamily requires mutuality, relays would have to include (hashed?) bridge fingerprints in their MyFamily or do you propose an exception in the bridge case?
  • If we do not require a mutual MyFamily agreement in the bridge-case.

This would open a new attack opportunity: Attacker creates a bridge: list all exits except those that are operated by himself to force the client towards exits that are under his control.

comment:4 in reply to:  description ; Changed 2 years ago by arma

Replying to isis:

1) Warn bridge operators not to include other bridges in MyFamily, but let them know that including relays is fine. We should continue to warn them not to list any bridge in the MyFamily of a public relay.
2) Allow bridges to specify MyFamily.

The MyFamily references, as currently designed, need to be bidirectional. Otherwise you could set up a bridge and request that anybody who uses your bridge should never use the following (innocent, unrelated, target) relays in their circuit, and really mess with path selection.

See #15060 for more discussion.

comment:6 in reply to:  4 Changed 2 years ago by isis

Replying to arma:

Replying to isis:

1) Warn bridge operators not to include other bridges in MyFamily, but let them know that including relays is fine. We should continue to warn them not to list any bridge in the MyFamily of a public relay.
2) Allow bridges to specify MyFamily.

The MyFamily references, as currently designed, need to be bidirectional. Otherwise you could set up a bridge and request that anybody who uses your bridge should never use the following (innocent, unrelated, target) relays in their circuit, and really mess with path selection.


Yes, and there are also other ways to mess with someone's path selection if you're their guard/bridge. Not that that means we should make it easier for them to do so, but I feel like a malicious bridge is going to behave maliciously no matter what we do with the MyFamily setting.

See #15060 for more discussion.


I'm not sure if "Wait for us to do something with a vague, two-years-old ticket" is the best response to "We have way more money than we thought and we want to give you free bandwidth"?

comment:7 Changed 2 years ago by cypherpunks

More exit bandwidth is also welcome, no?

Even if this is implemented (now) it would take a long time until this release gets to most tor users.

comment:8 Changed 2 years ago by dgoulet

Milestone: Tor: unspecified

Setting a milestone. Please change if a patch comes in or we really want that in a soon-next version.

comment:9 Changed 2 years ago by nickm

Keywords: tor-relay tor-bridge is-this-safe added

comment:10 Changed 2 weeks ago by phw

Cc: phw added
Note: See TracTickets for help on using tickets.