Opened 6 years ago

Closed 3 years ago

#9100 closed enhancement (not a bug)

It should be possible to introduce a single hidden service from more than one client

Reported by: andrea Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.4.14-alpha
Severity: Normal Keywords: tor-hs needs-proposal
Cc: andrea Actual Points:
Parent ID: Points:
Reviewer: Sponsor: None

Description

While I'm brain-dumping things that should be improved about hidden services...

For the sake of reliability and load balancing, it should be possible to introduce a single hidden service from multiple clients, and automatically get a reasonably balanced distribution of incoming connections sent to each introducing client. This can possibly help mitigate transient failures of the client, or DoS attempts, which have been reported via as yet unknown mechanism against certain prominent HSes recently [1].

(Question: what happens if you try to do this unofficially now, by copying the HS private key to another Tor?)

This could imply either each instance independently picking intro points and publishing a descriptor (simplest), but then other nodes might see the multiple conflicting descriptors and think something fishy is going on. We could allow descriptors which match in everything but the intro points to be merged (need to check: are the HSDirs chosen for a given HS a deterministic function of its key so the different clients would all publish to the same place to get merged?), but then we end up with large numbers of intro points (cf. #9002).

Finally, we could somehow try to make every instance of the HS pick the same set of intro points (how to coordinate, and is it dangerous if it's predictable by an attacker?) , and have the intro points effect load balancing by mapping incoming INTRODUCE1s into an INTRODUCE2 on one and only one incoming intro circuit.

Additional issue: right now, the client the HS is introduced from must have the HS private key. Load balancing like this means distributing n copies of the private key around, increasing the risk of compromise. It'd be helpful if instead they could use a subkey, distinct for each introducuing client and either expiring or revokable, with the real HS private key kept safely offline somewhere.

[1] https://twitter.com/maradydd/status/329332167731716096

Child Tickets

Change History (5)

comment:1 Changed 6 years ago by hsn

I also thinked about this idea but without subkeys. For start implementing it with copying same key around multiple times would be fine.

Something needs to be done in this area to make HS more attractive.

comment:2 Changed 6 years ago by hsn

This is very good reading about HS
http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf It describes "unknown dos against HS" and how to harvest list of HS.

comment:3 Changed 6 years ago by nickm

Keywords: tor-hs needs-proposal added

comment:4 Changed 4 years ago by dgoulet

I think OnionBalance here is a very good start to address this issue. There is still the advanced mode to be implemented if I'm not mistaken and further improvement. Here also more ideas and reference:

https://onionbalance.readthedocs.org/en/latest/
https://lists.torproject.org/pipermail/tor-dev/2015-October/009618.html

comment:5 Changed 3 years ago by dgoulet

Resolution: not a bug
Severity: Normal
Sponsor: None
Status: newclosed

I've talked about the state of this ticket with asn on #tor-dev. Closing this for the following reasons:

OnionBalance is a good approach here to address this and comment:4 has information about it.

Ideas here are mostly research ideas that should be discussed on tor-dev@ mailing list so if anything needs to be expanded from this ticket, let's do it there.

Note: See TracTickets for help on using tickets.