Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#4124 closed defect (fixed)

Bridges should use create_fast cells for the first hop of their circuits

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-bridge
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

A friendly anonymous user commented on #4115 that bridges can be distinguished by whether they use a create cell or create_fast cell. Once we fix #4115 it will be even more straightforward to distinguish.

should_use_create_fast_for_circuit(origin_circuit_t *circ)
{
  or_options_t *options = get_options();
  tor_assert(circ->cpath);
  tor_assert(circ->cpath->extend_info);

  if (!circ->cpath->extend_info->onion_key)
    return 1; /* our hand is forced: only a create_fast will work. */
  if (!options->FastFirstHopPK)
    return 0; /* we prefer to avoid create_fast */
  if (server_mode(options)) {
    /* We're a server, and we know an onion key. We can choose.
     * Prefer to blend in. */
    return 0;
  }

  return 1;
}

Bridge-detector example:

if (or_circ && !or_circ->is_first_hop && rh.command == RELAY_COMMAND_BEGIN_DIR) {
  /* non-mirror relay detected or bridge, filter it by consensus. */

Child Tickets

Change History (21)

comment:1 Changed 8 years ago by arma

Resolution: fixed
Status: newclosed

Fixed in git commit ff8aba7053. Let me know if I actually didn't fix it!

comment:2 Changed 8 years ago by rransom

I thought the easy way for a relay to detect a bridge was that bridges' clients' circuits don't use CREATE_FAST cells on the hop from the bridge to the relay. The fix for that is to turn off FastFirstHopPK, and that requires that we implement and deploy a new (faster) circuit-extension handshake.

comment:3 Changed 8 years ago by nickm

That's one way to detect bridges, and that's one fix for it. We need a general "let's make connections from bridges harder to detect" ticket.

comment:4 Changed 8 years ago by nickm

Resolution: fixed
Status: closedreopened

Hm. With that in mind, though, I think this should maybe get reverted.

It doesn't make bridges harder to detect; it just makes their circuits distinguishable from their clients' circuits.

comment:5 Changed 8 years ago by arma

I'm not opposed to reverting.

But just to clarify our understanding, there remain (at least) three ways to distinguish bridges:

A) When they do a begindir request to you it's from a circuit that was made with a create cell
B) When they make a circuit to you on behalf of a bridge user it is made with a create cell
C) If it makes a circuit to and through you and you don't have the Guard flag, it's probably on behalf of a bridge user.

This patch fixed A, but didn't fix B, and C remains as well. B and C are both expected to be resolved by our upcoming "bridges insert an extra guard hop themselves" proposal. When we do that proposal, will we want (and like) our fix for A here? I am expecting yes. But maybe reverting until we have the proposal is smart.

comment:6 Changed 8 years ago by nickm

This patch was not just a fix for A; I thought it make *all* of the circuits from a bridge use a CREATE_FAST cell.

comment:7 in reply to:  6 ; Changed 8 years ago by arma

Replying to nickm:

This patch was not just a fix for A; I thought it make *all* of the circuits from a bridge use a CREATE_FAST cell.

No, should_use_create_fast_for_circuit() is only considered in the context of origin circuits (i.e. circuits that have a cpath).

It has nothing to do with circuits that originated elsewhere.

comment:8 in reply to:  7 Changed 8 years ago by arma

Replying to arma:

Replying to nickm:

This patch was not just a fix for A; I thought it make *all* of the circuits from a bridge use a CREATE_FAST cell.

No, should_use_create_fast_for_circuit() is only considered in the context of origin circuits (i.e. circuits that have a cpath).

Oh. By "all" you mean "all origin circuits". And yes, it does.

comment:9 Changed 8 years ago by arma

Ok, I amend (A) above to "when they make a circuit to you that originates at the bridge"

comment:10 Changed 8 years ago by nickm

rransom above correctly identified the long-term solution for A; this isn't it.

The question I want to answer *now* is whether this patch -- the one we have merged now -- is a good idea *now* or whether we should revert it.

It makes one thing better: it makes it harder to identify bridges before they see use.

It makes one thing worse: it makes the circuits that originate at a bridge distinguishable from circuits that don't.

Is this tradeoff a win?

comment:11 Changed 8 years ago by arma

Milestone: Tor: 0.2.2.x-finalTor: 0.2.3.x-final
Priority: majornormal

I'm going to revert it until we have a proposal and patch for B and C, at which time we can reevaluate.

comment:12 in reply to:  10 Changed 8 years ago by rransom

Replying to nickm:

rransom above correctly identified the long-term solution for A; this isn't it.

The question I want to answer *now* is whether this patch -- the one we have merged now -- is a good idea *now* or whether we should revert it.

It makes one thing better: it makes it harder to identify bridges before they see use.

It makes one thing worse: it makes the circuits that originate at a bridge distinguishable from circuits that don't.

Is this tradeoff a win?

Two types of circuits originate from a bridge: single-hop directory-fetch circuits and circuits for anonymous activities. Single-hop dir-fetch circuits from a bridge are trivially distinguishable from a bridge's clients' circuits. Circuits for anonymous activities are all sent through the bridge's three entry guards. Most of a bridge's clients' circuits will not be sent through from the bridge through one of those three relays.

Yes, this tradeoff is a win; we should not revert arma's patch.

comment:13 Changed 8 years ago by nickm

Good point. Can we make it so that we use CREATE_FAST cells only for the begindir stuff?

comment:14 in reply to:  13 Changed 8 years ago by arma

Replying to nickm:

Good point. Can we make it so that we use CREATE_FAST cells only for the begindir stuff?

If circ->build_state->onehop_tunnel then return 0.

comment:15 Changed 8 years ago by arma

and by return 0 maybe I mean return 1 ;)

comment:16 in reply to:  13 ; Changed 8 years ago by arma

Replying to nickm:

Good point. Can we make it so that we use CREATE_FAST cells only for the begindir stuff?

Here's the patch for that. Note that in writing it I became convinced it's a poor idea.

   if (!options->FastFirstHopPK)
     return 0; /* we prefer to avoid create_fast */
+  if (options->BridgeRelay) {
+    /* If we're a bridge, then we want to use create_fast cells like a
+     * normal user for our one-hop begindir connections, because we
+     * potentially connect to many different relays so looking different
+     * from a client is too risky. But for normal circuits to one of our
+     * guards, choose to stand out as a bridge rather than look like a
+     * client, so the guard can't tell whether this circuit is from us
+     * or from one of the users of our bridge, even though none of
+     * our bridge users would extend a circuit to our guard since he
+     * has the Guard flag. See bug 4124. */
+    return circ->build_state->onehop_tunnel;
+  }
   if (public_server_mode(options)) {

comment:17 in reply to:  16 ; Changed 8 years ago by rransom

Replying to arma:

Here's the patch for that. Note that in writing it I became convinced it's a poor idea.

+     * guards, choose to stand out as a bridge rather than look like a
+     * client, so the guard can't tell whether this circuit is from us
+     * or from one of the users of our bridge, even though none of
+     * our bridge users would extend a circuit to our guard since he
+     * has the Guard flag. See bug 4124. */

It shouldn't be ‘none’, but I agree that the probability that a bridge's client would extend to one of the bridge's entry guards is sufficiently low that using CREATE_FAST for every circuit originating from a bridge is acceptable.

But I also don't see a problem with a bridge's entry guards knowing that it is a bridge, and I don't expect to be able to conceal that fact from them when we change Tor to shove a bridge's clients' circuits through the bridge's entry guards.

comment:18 in reply to:  17 ; Changed 8 years ago by arma

Replying to rransom:

It shouldn't be ‘none’, but I agree that the probability that a bridge's client would extend to one of the bridge's entry guards is sufficiently low that using CREATE_FAST for every circuit originating from a bridge is acceptable.

Right now we're in case 2b of network balancing:
Sep 28 16:55:01.000 [notice] Computed bandwidth weights for Case 2b2 (Wgg=1, Wee=1) with v10: G=1130211 M=467818 E=431139 D=1473927 T=3503095

But yes, in the general case it might be 'few' rather than 'none'.

But I also don't see a problem with a bridge's entry guards knowing that it is a bridge, and I don't expect to be able to conceal that fact from them when we change Tor to shove a bridge's clients' circuits through the bridge's entry guards.

We could in theory have bridges shove their clients' circuits through some other set of guards, when the time comes.

So, in conclusion, the plan here is to leave the patch in place, not revert, and close the ticket? And then open a fresh ticket to be the mommy ticket for our growing number of "make bridges harder to enumerate" issues.

comment:19 in reply to:  18 Changed 8 years ago by rransom

Resolution: fixed
Status: reopenedclosed

Replying to arma:

So, in conclusion, the plan here is to leave the patch in place, not revert, and close the ticket? And then open a fresh ticket to be the mommy ticket for our growing number of "make bridges harder to enumerate" issues.

Yes.

comment:20 Changed 7 years ago by nickm

Keywords: tor-bridge added

comment:21 Changed 7 years ago by nickm

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