[tor-dev] [Question to sysadmins and HS operators:] How should Hidden Services scale?

[George Kadianakis]

As some people said, another aspect of this project is increasing the
'availability' of hidden services.

That is, increasing the number of nodes of a Hidden Service so that even
if one is down, the rest can still handle clients. This is not something
that application-layer solutions like HAProxy can solve.

This even has security implications for Hidden Services since DoS attacks
can lead to privacy attacks. For example, if someone suspects that a
Hidden Service is hosted on a specific IP, they can shut down the IP and
do a confirmation attack by checking if the HS is reachable anymore. If
it's not reachable, chances are that the suspicion was correct.

If we could somehow allow multiple nodes to handle introductions and
rendezvous requests, we might be able to make HSes more secure against DoS
confirmation attacks like the above.

Unfortunately, this doesn't seem easy to do properly [0]. And of course,
an attacker can still do confirmation attacks after the rendezvous is
done, by sending specific amounts of data to the HS and checking the
network of the suspected IP for that amount of incoming data...

[0]:  For example, the proposed "scalable HS" solutions allow multiple
nodes to handle introductions for an HS, but in the proposed designs the
same node that handles the introduction is also the one that handles the
rendezvous. If an attacker suspects a specific node to be part of an HS,
she can do an introduction to it, then DoS it, and see if the node ever
appears in the rendezvous point. If it doesn't, then the confirmation
might be successful. There are probably even more subtle attacks that an
attacker can do if she wants to do a confirmation attack against an HS
node during the introduction or rendezvous steps.