[tor-bugs] #15540 [Tor]: Increase the capacity of a HS server by using bridges after we implement Prop 188

[Tor Bug Tracker & Wiki]

#15540: Increase the capacity of a HS server by using bridges after we implement
Prop 188
-----------------------------+-----------------------------------------
     Reporter:  s7r          |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-hs, prop188, tor-bridge
Actual Points:               |  Parent ID:  #15463
       Points:               |
-----------------------------+-----------------------------------------

Comment (by isis):

 Some minor comments and feedback.

 Replying to [ticket:15540 s7r]:
 > […]
 > We are also under the assumption that clients building 4 hop circuits in
 the network are not easily distinguished (confirmation for this would be
 great).

 Clients building 4-hop circuits are maybe distinguishable, so this might
 not be a fair assumption.

 For some time before Tor-0.2.3.x, if you think you're a guard, you would
 do this by counting the number of RELAY_EARLY cells which pass through
 you. However, nowadays, after an OP finishes doing all of its EXTENDs
 (which are always packaged inside RELAY_EARLY cells), the OP sends some
 vagueish number (totalling either 8 or 9, IIRC) of their actual RELAY
 cells packaged inside RELAY_EARLY cells, in order to attempt to conceal
 the length of the circuit. However, there are probably still ways to
 determine the length of a circuit if you believe you're the guard (i.e. by
 attempting to learn from the RT timings or something like that).

 > Regardless of this and unrelated, prop 188 should be implemented anyway,
 because it protects the bridge-db.

 Prop!#188 might technically harm BridgeDB: if an adversary can no longer
 run middle nodes, wait for things which aren't in the consensus to connect
 to them, and thus passively gather a list of bridges, then the adversary's
 best mode of attack falls back to attempting to enumerate bridges via
 BridgeDB.  (Which is fine, since we've got a pretty good plan for
 preventing that, which will also soon be implemented.)

 > Let's say prop 188 is implemented, so each bridge selects a Guard and
 keeps it static for as long as the consensus recommends so (same behavior
 as a regular Tor client). A big HS server would use bridges to connect to
 the Tor network. The bridges can either be from bridge-db, or, if the HS
 operator is concerned about performance and availability, the bridges can
 also be high speed, dedicated and private (PublishServerDescriptor 0), or
 someone can run high speed public bridges (PublishServerDescriptor 1) and
 use those.
 >
 > According to prop 188, when used with bridges, Tor will build 4 hop
 circuits:
 > {{   Finally, observe that even though the circuit is one hop longer
 than it would be otherwise, no relay's count of permissible RELAY_EARLY
 cells falls lower than it otherwise would.  This is because the extra hop
 that Bob adds is done with a CREATE_FAST cell, and so he does not need to
 send any RELAY_EARLY cells not originated by Alice.   }}
 >
 >    Something as follows:
 >    HS Server -> bridge(s) -> Guard(s) as per prop 188 -> middle ->
 middle -> rendezvous
 > Each bridge could be a false positive for the HS server, in case an
 attacker discovers the bridge's guard.

 If we implement this, or encourage people to do this, then we should
 update all of our documentation which says that "it's totally safe,
 legally and otherwise, to run a bridge because no traffic is exiting from
 you".

 > Questions:
 > 1.For prop 188, who will choose and remember the bridge's Guard? The
 client connecting to the bridge or the bridge itself?

 The bridge chooses its guard, and uses tor's (accidental) loose-source
 routing feature to transparently insert the guard into the client's
 circuit. The client doesn't even have to know that she is technically
 using a 4-hop circuit.

 (At least, this is the way I've implemented it for #7144.)

 > 2.Would it help if we could optionally add more Guards for the same
 bridge (something like NumBridgeEntryGuards)?

 In order to protect the bridges from being discovered, I would prefer that
 bridges simply use the NumGuards parameter so that they behave (as much as
 possible) like normal clients.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15540#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online