Increase the capacity of a HS server by using bridges after we implement Prop 188
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)?