[tor-dev] Proposal 247 (Hidden Service Vanguards) Overhaul and Proposal: Padding Negotiation

[Mike Perry]

Tim Wilson-Brown - teor:
> 
> > On 14 Sep 2015, at 09:07, Mike Perry <mikeperry at torproject.org>
> > wrote:
> > 
> > ...
> > 
> > 
> > 4. 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 at 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.


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150913/739f3bb1/attachment.sig>