Opened 2 years ago

Last modified 5 months ago

#23278 reopened enhancement

Give user option to use non-Exit Guards only

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client, tor-config
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Bridges is absolute right way to solve such requests, but could be overkill solution.

Child Tickets

Change History (10)

comment:1 Changed 2 years ago by cypherpunks

comment:2 Changed 2 years ago by cypherpunks

Possible solution, need more discussion if it works and safe:

/**
 * Return true iff <b>node</b> is a Tor relay that we are configured to
 * be able to connect to. */
static int
node_passes_guard_filter(const or_options_t *options,
                         const node_t *node)
{

  if (options->StopGulagsFear &&
      (node->is_exit || ! node_exit_policy_rejects_all(node)))
    return 0;
Last edited 2 years ago by cypherpunks (previous) (diff)

comment:3 Changed 2 years ago by cypherpunks

This is time wasting. Next level will be to catch everyone who used Tor three days before event, then to catch everyone who was online. Finally to catch all yet alive, and catch itself as grand final. Gulag must be outlawed. Stop cooperate with them, stop legitimate them.

Ticket need to be closed as wontfix.

comment:4 Changed 2 years ago by arma

Today it is already the case that Tor clients use non-Exit Guards only.

That's because of the load balancing that's done based on proportions of what capacities are available in the network.

Specifically, right now Exit capacity is scarce in the network, so every relay that has both the Guard flag and the Exit flag is always avoided when clients are picking a guard, since they know to leave its bandwidth available for people who are using it as an exit.

comment:5 Changed 2 years ago by arma

(The Russian news story says that a Tor user connected to a Tor exit relay in France at the same time as that exit relay did something bad. It sounds like somebody is misunderstanding that Tor circuits use multiple hops -- and since they never use the same relay more than once in a path, the fact that this user connected to that relay for his first hop means he definitely did *not* use the relay as his exit.)

comment:6 Changed 2 years ago by cypherpunks

Specifically, right now Exit capacity is scarce in the network, so every relay that has both the Guard flag and the Exit flag is always avoided when clients are picking a guard, since they know to leave its bandwidth available for people who are using it as an exit.

More specifically, it depends bandwidth-weights generated by DirAuths for consensus document. bandwidth-weights are dynamic depends network's weather.

Simplified code to compute Guard bandwidth by client for Exit+Guard case:

Wd = networkstatus_get_bw_weight(NULL, "Wgd", -1);
Wdb = networkstatus_get_bw_weight(NULL, "Wdb", -1);
//Today: Wdb=10000 Wgd=0
weight = (is_dir ? Wdb*Wd : Wd); // 0 or 0 for today
final_weight = weight*this_bw; //  0 for WEIGHT_FOR_GUARD
bandwidths[node_sl_idx] = final_weight + 0.5;

0.5 is not zero after all. It is today, not yesterday or tomorrow.

comment:7 Changed 2 years ago by dgoulet

Resolution: not a bug
Status: newclosed

comment:8 Changed 2 years ago by dgoulet

Keywords: tor-client tor-config added
Milestone: Tor: unspecified
Resolution: not a bug
Status: closedreopened

Ok some clarification went down on IRC so here it is.

Because of #23318, it seems that a "paranoid mode" option would be what the reporter of this bug wants that is an option that makes tor never pick a Guard that has a non empty exit policy (basically an exit node). And that paranoid mode would be all about avoiding that behavior in case of a bad bug (maybe like #23318) in tor even though tor should never do that.

Plausible?

comment:9 Changed 2 years ago by cypherpunks

And that paranoid mode would be all about avoiding that behavior in case of a bad bug (maybe like #23318) in tor even though tor should never do that.

Tor client can to pick Guard with "accept *:443; reject *:*" exit policy, which is not enough for relay to get Exit flag but enough to use it as exit relay. Actually there are many real non-Exit (flag) Guards with more complex exit policies that can be used as exits too (there many protocols nasty people can do nasty things).

Why Paranoid mode -- many such Guards have a "history" as they already listed in some "block lists" or will be listed in cops lists in future. This option for paranoid people who might need more than default settings but is not ready to use Bridges yet. (Some dictatorship or hybrid regimes using some kind of collective punishment)

comment:10 in reply to:  8 Changed 5 months ago by cypherpunks

Replying to dgoulet:

Because of #23318, it seems that a "paranoid mode" option would be what the reporter of this bug wants that is an option that makes tor never pick a Guard that has a non empty exit policy

actually the consensus weight for exitguards is nearly ZERO for guard probability. your client shouldn't pick and use it as guard. well at least it have the exit flag.

Replying to cypherpunks:

Tor client can to pick Guard with "accept *:443; reject *:*" exit policy, which is not enough for relay to get Exit flag but enough to use it as exit relay. Actually there are many real non-Exit (flag) Guards with more complex exit policies that can be used as exits too (there many protocols nasty people can do nasty things).

is there a easy way to find such relays? without searching through whole consensus desciptors like a metrics relay search pattern? flag:!exit ... i tried find them through https://check.torproject.org/cgi-bin/TorBulkExitList.py but had no luck yet.

Note: See TracTickets for help on using tickets.