Opened 4 years ago

Last modified 3 months ago

#15540 new enhancement

Increase the capacity of a HS server by using bridges after we implement Prop 188

Reported by: s7r Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, prop188, tor-bridge, prop247, vanguards
Cc: isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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)?

Child Tickets

Change History (8)

comment:1 Changed 4 years ago by isis

Cc: isis added
Keywords: prop188 tor-bridge added

Adding myself and some keywords to make this easier for me to find later.

comment:2 in reply to:  description Changed 4 years ago by isis

Some minor comments and feedback.

Replying to 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.

comment:3 Changed 4 years ago by teor

Milestone: Tor: 0.2.???

comment:4 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:5 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:6 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:7 Changed 2 years ago by nickm

Keywords: prop247 vanguards added
Severity: Normal

Also see prop247.

comment:8 Changed 3 months ago by asn

Parent ID: #15463
Note: See TracTickets for help on using tickets.