Opened 7 months ago

Last modified 3 months ago

#26768 new defect

Support onionbalance in HSv3

Reported by: asn Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs scaling onionbalance
Cc: s7r Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by nickm)

HSv3 need some mods to support the onionbalance design.

That's because of the cross-certs of the intro key in the descriptor (with the desc signing key). Which means that the onionbalance node would need to know the intro privkey to be able to complete the cross-cert with its own descriptor signing key.

Here is an approach to route around this with v3 coming from the Seattle hackfest:

The descriptor-signing private key for each day is generated based on a hash of a shared secret that is shared between the onion service controller and the onion service instances. This way, the instances know what the signing key for each day will be. [Because this is a signing key, forward secrecy is not endangered.]

When uploading descriptors, the instances generate "bogus" descriptors (associated with different identity keys) containing intro points and keys generated in a way suitable for including in the combined service's onion descriptor. They cross-certify the master signing key, not their own descriptors' signing keys. They upload these descriptors to the hash ring. They look normal to the hash ring directory servers, since only the encrypted parts are weird.

To generate the combined descriptors, the service controller periodically downloads all the "bogus" descriptors above, and stuffs their contents into a combined descriptor.

Since the shared secret produces the descriptor keys, the instances can also produce descriptors with the valid descriptor signing key generated from the shared secret.

Instances can optionally use client authentication.

This is quite a bit of mods to support onionbalance, but it does seem like a plausible approach.

We should investigate more and move forward here!

Child Tickets

Change History (3)

comment:1 Changed 7 months ago by nickm

Description: modified (diff)

comment:2 Changed 5 months ago by s7r

Cc: s7r added

comment:3 Changed 3 months ago by asn

Just some notes from a recent discussion about onionbalance vs the current poor man's onionbalance where every node races each other for uploading descriptors:

With the poor man's solution, there are issues when you start removing/rebooting nodes, since if the offline node currently has the active descriptor there will be reachability issues until another node wins the race.

We could fix this by making all nodes upload more frequently, and be able to pause publishes from the rebooting node, and also by ensuring that all clients will re-fetch descriptors smoothly if they can't connect to the intro points.

Note: See TracTickets for help on using tickets.