[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:
 Keywords:  tor-hs       |  Actual Points:
Parent ID:  #15463       |         Points:
-------------------------+---------------------
 Will try to keep the post in a reasonable size.

 Long story short, the first bottleneck when running a big HS is the Guard
 server. Given the fact that all the traffic to or from a HS has to go
 through the Guard server, the Guard's capacity is actually the max. limit.
 The server hosting the HS can be a ten-gigabit server, it won't matter if
 the Guard's capacity is 5MB/s (and that is also shared with other clients
 using the same guard). Currently the only way you can increase the
 capacity of a HS is to increase NumEntryGuards value and
 MaxClientCircuitsPending value.

 Will describe a possible solution for this which could be possible after
 we implement prop 188. 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). Regardless of this and unrelated,
 prop 188 should be implemented anyway, because it protects the bridge-db.

 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.
 In this scenario, if the bridge's IP is discovered by an attacker, the HS
 server is better protected if it uses a bridge from bridge-db (which also
 handles other clients) as opposite to a dedicated private bridge.

 If we use the bridges with pluggable transports, we will also mitigate a
 different type of attack (where an ISP, network administrator, datacenter
 looks for IP addresses which send and receive massive amounts of Tor
 traffic but do not belong to Tor relays).

 It is known that having more points of entry in the Tor network means a
 higher probability to get deanon, but big HSes need to handle many
 concurrent clients - a bit hard to do through a single guard.

 Questions:
 1.For prop 188, who will choose and remember the bridge's Guard? The
 client connecting to the bridge or the bridge itself?
 sysrqb and Yawning think that it's better for the client to select and
 remember the guard for a bridge. This way, a client using Tor with bridges
 will have chances to get deanon as low as a client using Tor normally. In
 its current form today, prop 188 suggest that bridges choose their own
 guards.

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

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