[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #9100 [Tor]: It should be possible to introduce a single hidden service from more than one client
#9100: It should be possible to introduce a single hidden service from more than
one client
-------------------------+--------------------------------------------------
Reporter: andrea | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Tor: unspecified
Component: Tor | Version: Tor: 0.2.4.14-alpha
Keywords: | Parent:
Points: | Actualpoints:
-------------------------+--------------------------------------------------
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
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9100>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs