[tor-dev] Hidden Service Scaling

[Matthew Finkel]

On Sun, Oct 13, 2013 at 10:22:29PM +0100, Christopher Baines wrote:
> On 09/10/13 18:05, Matthew Finkel wrote:
> >>>> These two changes combined should help with the two goals. Reliability
> >>>> is improved by having multiple OP's providing the service, and having
> >>>> all of these accessible from the introduction points. Scalability is
> >>>> also improved, as you are not limited to one OP (as described above,
> >>>> currently you can also have +1 but only one will receive most of the
> >>>> traffic, and fail over is slow).
> >>>  
> >>> Do you see any disadvantages to this design?
> >>
> >> So, care needs to be taken around the interaction between the hidden
> >> service instances, and the introduction points. If each instance just
> >> makes one circuit, then this reveals the number of instances.
> > 
> > Does it?
> 
> Given the above, that is, each instance of the hidden serivce connects
> once to each introduction point. Then the number of instances of a
> hidden service, is equal to the number of connections with that each
> introduction point sees with that key.
> 

Ah, I missed something earlier, this makes more sense now. Thanks for
reiterating that point.

So, this having been said, do you have some thoughts on how to counter
this? At this point, introduction points are selected at random, it will
be unforunate if they can build a profile of a hidden service's usage
over time.

> >> There is also uncertainty around the replacement of failing introduction
> >> points. New ones have to be chosen, but as the service instances do not
> >> directly communicate, there could be some interesting behaviour unless
> >> this is done carefully.
> > 
> > Is there a reason they shouldn't communicate with each other?
> 
> I have avoided it so far, as it increases the complexity both the
> implementation and setup. However, this is probably a minor issue, as
> the major issue is how service providers would want to use this? Complex
> hidden services (compared to hidden services with static content) will
> probably require either communication between instances, or
> communication from all instances to another server (set of servers)?

It will surely increase the complexity, however allowing the hidden
service peers to coordinate their introduction points (and/or other
information) could be a useful feature. This could be especially true
if we want to address the "all introduction points know the number of
hidden service instances that constitute a hidden service address"
problem.

As a general rule, we want to minimize the number of nodes that are
given a priviledged position within the network. As an example, if
we go back to my earlier comment and assume all instances of a
hidden service use the same introduction points, then a client will
use any one of the introduction points with equal probability. Given
this, an introduction point 1) knows the size (number of instances) of
the hidden service, 2) can influence which hidden service instances are
used by clients, 3) can communicate with a HS without knowing who it is,
and 4) can potentially determine the geographical location of the hidden
service's users (based on when it is used). These last few points are
not unique to your design and the last point is not unique to
introduction points, but these leakages are important and we should try
to account for them (and plug them, if possible). (This is not an
exhaustive list)

> >>>> I am aware that there are several undefined parts of the above
> >>>> description, e.g. how does a introduction point choose what circuit to
> >>>> use? but at the moment I am more interested in the wider picture. It
> >>>> would be good to get some feedback on this.
> >>>>
> >>>> 1: https://blog.torproject.org/blog/hidden-services-need-some-love
> >>>> 2:
> >>>> http://tor.stackexchange.com/questions/13/can-a-hidden-service-be-hosted-by-multiple-instances-of-tor/24#24
> >>>
> >>> This is a good start! Some important criteria you might also think
> >>> about include how much you trust each component/node and which nodes do
> >>> you want to be responsible for deciding where connections are routed.
> >>> Also seriously think about how something like a botnet that uses hidden
> >>> services might impact the reliability of your design (crazy idea, I
> >>> know).
> >>
> >> I assume the characteristics of this are: 1 or more hidden service
> >> instances, connected to by very large numbers of clients, sending and
> >> reviving small amounts of information?
> > 
> > Perhaps, but just think about the load an intro point can handle and
> > sustain. If Introduction Points are where load balacing takes place,
> > then does this affect the difficulty of attacking a hidden service? (for
> > some undefined definition of 'attack'.)
> 
> At the moment, I am really considering the redundancy and scalibility of
> the serivce. Both of these could be helped by allowing for
> multi-instance hidden serivces (in a planned and thought through manor).
> Hopefully allowing for this will increase the difficulty to attack
> hidden serivce, not directly, but by allowing the operators to use this
> functionality.

Understood, and I appreciate this concentration, but also try to keep
in mind that, while you work on this design, if you are faced with a
tradeoff between scalability/reliability and anonymity, default to
anonymity.