[tor-talk] Massive Bandwidth Onion Services

[David Goulet]

On 19 Dec (09:04:46), Allen wrote:
> AFAIK, HiddenServiceNumIntroductionPoints >= 3 is also for the benefit
> of the client, so if intro point #1 doesn't work for the client, it
> can try to connect at intro point #2, and then finally at intro point
> #3 before giving up.  So let's say my Tor client looks up your Tor
> hidden service descriptor and attempts to connect at intro point #1
> and that fails.  What would/should it do at that point?  Give up?

Good point! To clarify here the client behavior in that case

Your tor client will add that intro point in a "failure cache" which will stay
in there for 5 minutes (yeah... possibly way too high! ticket #17520) and then
if you have a descriptor that has *no* more usable intro points (that is they
are all in the failure cache), a fetch will be triggered on the remaining set
of HSDir you haven't lookup for a hopefully new descriptor. Then that new
descriptor intro points are checked agains that failure cache and will be used
accordingly.

So, in this case with 1 single intro point that fails, the client will ask
another HSDir for a new descriptor and so on...

More comment below.

> 
> On Mon, Dec 19, 2016 at 5:47 AM, Alec Muffett <alec.muffett at gmail.com> wrote:
> > As an aside, this is what I am currently using as a daemon config.
> > Comments welcome.
> >
> > I'm trying not to use Guards because again it would be rude to hammer them
> > with vast data flows when instead the pain can be spread around a bit more;
> > given that my target deployments are unlikely to be truly anonymous (eg:
> > Facebook) this isn't much of an anonymity issue.
> >
> >
> > $ more /home/alecm/master/halfagig/hs6.d/config
> > DataDirectory /home/alecm/master/halfagig/hs6.d
> > HiddenServiceDir /home/alecm/master/halfagig/hs6.d/
> > # HiddenServicePort 19 localhost:8506 # chargen, eventually
> > HiddenServicePort 80 localhost:10506
> > HiddenServiceNumIntroductionPoints 3 # <--- maybe 2 or 1 here?

Fun fact, I believe this is a bug....

0 intro point is actually suppose to be allowed as it is an easy way to
"disable" your service and a valid case as well. Not only that, but the
documentation does NOT specifies anything about a lower limit...

I just opened: https://trac.torproject.org/projects/tor/ticket/21033

> > LongLivedPorts 19,80
> > #
> > CircuitBuildTimeout 60
> > LearnCircuitBuildTimeout 0
> > PredictedPortsRelevanceTime 0
> > RendPostPeriod 37 minutes

Ok so here is the thing. I would put some "advisory" on your setup here as
default values are changed for the descriptor.

Because of design issues in the current HS protocol, any HSDir can learn the
amount of introduction points you have meaning if you change it from the
default value, you'll increase the chances of being more identifiable as you
"don't look like the others".

Second, same occurs with modifying that RendPostPeriod from the default value
of an hour to a custom time time. It makes you a bit more noticeable because
you have a different behavior then anyone else.

(And possibly some effect of disabling LearnCircuitBuildTimeout).

Those do not lead to an "automatic deanonymization" but lets say they won't
help. However, in the case of a single onion service (just release stable few
minutes ago :D), this is really great!

Thanks Alec!
David

> > SocksPort 0
> > UseEntryGuards 0
> > UseEntryGuardsAsDirGuards 0
> > --
> > tor-talk mailing list - tor-talk at lists.torproject.org
> > To unsubscribe or change other settings go to
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> -- 
> tor-talk mailing list - tor-talk at lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20161219/57f19451/attachment.sig>