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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx > > To unsubscribe or change other settings go to > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > -- > tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Attachment:
signature.asc
Description: PGP signature
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk