[tor-dev] Question about hidden services shared by multiple hosts

[Holmes Wilson]

Interesting!

So it seems important to not have two clients hosting the same onion
address at the same time, which is doable, and then we have to figure out
this revision counter.

What happens if the revision counter is not incremented correctly?

Is it that the now offline host could become the destination for incoming
traffic to the onion address?

Thanks so much for this feedback!
Holmes




On Fri, Apr 2, 2021 at 1:41 PM David Goulet <dgoulet at torproject.org> wrote:

> On 26 Mar (08:55:54), Holmes Wilson wrote:
> > Hi everyone,
>
> Greetings,
>
> >
> > We’re working on a peer-to-peer group chat app where peers connect over
> v3
> > onion addresses.
> >
> > One issue are groups where there are many users but only a few are
> online in
> > a given moment.  Onion addresses are forever, and existing peers might
> know
> > every peer in the network, but it will take a while to try connecting to
> all
> > of them to find one that is online.
> >
> > In this case, it seems helpful for one or more peers to share one or more
> > onion addresses that would serve as reliable  “trackers", e.g.
> >
> > 1. All members know the keypairs for these addresses.
> > 2. All online members ping these addresses at random intervals to say
> >    they’re online.
> > 3. If they can’t connect to an address, they start hosting it themselves.
> >
> > We’re going to start testing it, but we’re wondering if folks here know
> the
> > likely outcome of trying to “share” hosting of an onion service in this
> > spontaneous-volunteer sort of way and if there are downsides.
> >
> > I *think* the most important question is how long it takes for the
> network
> > to stop routing incoming traffic to an offline client when there’s an
> online
> > one available. How long will the address likely be unreachable in one of
> > these transition moments, assuming some peer immediately detects that a
> > “tracker” onion address has gone offline and begins hosting it
> themselves?
> > (And does this question make sense?)
>
> Interesting idea!
>
> So sharing onion address key material between peers can be fine until they
> are
> used at the same time. What will happen is that the two peers hosting the
> same
> onion address (service) will start competing on the onion service directory
> side where service's upload what we call a "descriptor" which is what
> client
> fetch in order to initiate a connection to the service.
>
> With v3, it gets even more complicated actually because of the "revision
> counter" in the descriptor which v2 didn't have.
>
> It is simply a number that keeps going up in the descriptor so the onion
> service directory (relay) doesn't accept a previous descriptor (replay).
> And
> so, your two peers sharing the onion keys will require to somehow sync that
> revision counter for your idea to work (located on disk in the state file,
> "HidServRevCounter").
>
> Else, one will inevitably be higher than the other and thus will always
> succeed where it will always fail for the other peer.
>
> One approach here, and it is a hack of course, is for the second peer
> detecting that the onion is down to download the descriptor (offline one)
> still on the directory, get the revision counter out of it
> ("revision-counter"
> field), do a +1 on it and set its state file with it. It is a hack but
> would
> work... You will likely have to deal with "descriptor not found anymore on
> the
> directories" and so you could bruteforce the revision counter from your
> last
> one like adding +1000 to it and that might do the trick. But I would
> definitely avoid as much as possible brute forcing it by small steps else
> your
> service will add undesirable load to the network with a lot of upload
> attempts.
>
> Now lets say you are able to pull that off, if I understand your question
> correctly, once an onion address goes offline, if the other peer would
> become
> the service then few seconds later, all clients will be able to connect to
> it.
> In other words, launching a new service takes few seconds before it can be
> reached. The new descriptor will be used by the directories immediately
> upon
> upload as long as the revision counter is higher than the previous one :).
>
> Hope this help!
> David
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20210403/97ba12c7/attachment.htm>