Tim Wilson-Brown - teor:
On 14 Sep 2015, at 09:07, Mike Perry mikeperry@torproject.org wrote:
...
- Security concerns and mitigations
4.1. Mitigating fingerprinting of new HS circuits
By pinning the middle nodes of rendezvous circuits, we make it easier for all hops of the circuit to detect that they are part of a special hidden service circuit with varying degrees of certainty.
...
The most serious of these is the Guard fingerprinting issue. When proposal xxx-padding-negotiation is implemented, services that enable this feature should use those padding primitives to create fake circuits to random middle nodes that are not their guards, in an attempt to look more like a client.
How will this interact with the rate limiting in xxx-padding-negotiation section 4.1?
On 12 Sep 2015, at 10:34, Mike Perry mikeperry@torproject.org wrote:
4.1. Rate limiting
...
We recommend that three consensus parameters be used in the event that the network is being overloaded from padding to such a degree that padding requests should be ignored:
- CircuitPaddingMaxRatio - The maximum ratio of padding traffic to
non-padding traffic (expressed as a percent) to allow on a circuit before ceasing to pad. Ex: 75 means 75 padding packets for every 100 non-padding packets. - Default: 100 * CircuitPaddingLimitCount
- The number of padding cells that must be transmitted before the
ratio limit is applied. - Default: 500 * CircuitPaddingLimitTime - The time period in seconds over which to count padding cells for application of the ratio limit. - Default: 60
XXX: Should we cap padding at these rates, or fully disable it once they're crossed?
If the rate limiting is being applied, that will limit fake middle circuits (with few non-padding packets) to ~500 cells per minute (~4KBytes per second).
Hrmm.. More importantly, 500 cells is only roughly 250kb, and apparently the average webpage size has ballooned to up to 1.6M: http://www.websiteoptimization.com/speed/tweak/average-web-page/
I've boosted the default here to 5000, so we can give this case a chance at pretending to fetch web pages.
Does CircuitPaddingLimitCount reset after CircuitPaddingLimitTime? (I can’t tell from the proposal, but I assume it has to reset, otherwise the limit is quite low, at 500 cells per fake circuit for its entire lifetime [plus whatever dribble it gets from non-padding cells].)
The count is meant to reset after CircuitPaddingLimitTime. I've clarified this and pushed again to my padding_negotiation branch.
Are those consensus parameters intended to be always set, or just set when there is an issue with padding? (I can see arguments both ways, but having them always set could be useful as a precaution against a quick attack.)
The way consensus parameters work in the Tor client code is that they have a hardcoded default value that is used if they are not present in the consensus. If a consensus value is present, it overrides this hardcoded value.
Hence it makes sense to set the defaults fairly liberally, and we'd only reduce them in the consensus if we noticed overload/abuse at relays.