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

[George Kadianakis]

David Goulet <dgoulet at torproject.org> writes:

> 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.
>

Hello all,

this revision counter sync issue is not a problem anymore since we
introduced the Order-Preserving-Encryption revision counter logic:
    https://gitlab.torproject.org/tpo/core/tor/-/blob/master/src/feature/hs/hs_service.c#L2979
    https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/rend-spec-v3.txt#L2548
Feel free to try it and let us know if it doesn't work. The solution
assumes that all peers have reasonably synchronized clocks.

In other news, the above "all members know all keypairs" approach seems
super dangerous in terms of security, especially if not all those
members are 100% trusted by each other.

To answer the performance question, if a peer immediately notices the
onion service being offline and begins hosting it, it should be
pretty-much immediately reachable by new clients.