Re: [tor-dev] Hidden Service Scaling

[George Kadianakis <desnacked@xxxxxxxxxx>]

Christopher Baines <cbaines8@xxxxxxxxx> writes:

> On 10/10/13 23:28, Paul Syverson wrote:
>> On Wed, Oct 09, 2013 at 03:02:47PM +0100, Christopher Baines wrote:
>>> On 09/10/13 11:41, Paul Syverson 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.
>>>>
>>>> You said something similar in response to Nick, specifically you said
>>>>
>>>>    I believe that to mask the state and possibly number of instances,
>>>>    you would have to at least have some of the introduction points
>>>>    connecting to multiple instances.
>>>>
>>>> I didn't understand why you said this in either place. Someone would
>>>> have to know they had a complete list of introduction points to
>>>> know the number of instances, but that would depend on how HS descriptors
>>>> are created, stored, and distributed. From whom is this being hidden?
>>>> You didn't state the adversary. Is it HS directory servers, intro point
>>>> operators, potential clients of a hidden service?  I don't see why
>>>> any of these necessarily learns the state or number of instances
>>>> simply because each intro point is chosen by a single instance
>>>> (ignoring coincidental collisions if these choices are not coordinated).
>>>
>>> To clarify, I was interpreting the goal as only the service operator
>>> should know the number of instances. In particular, the adversary here
>>> is the introduction point. If hidden service instances only ever create
>>> one circuit to each introduction point, each introduction point knows
>>> the number of instances of every service it is an introduction point
>>> for, as this is the same as the number of circuits for that service.
>>>
>> 
>> I'm missing something. Suppose there is a hidden service with ten
>> instances, each of which runs its own introduction point. How do any
>> of these ten introduction points know the number of instances because
>> they each see a single circuit from the hidden service?
>
> Ah, I have not been explicit enough when describing the behaviour I want
> to implement. In my original email, I set out that each instance of the
> service connects to each introduction point (this has also
> developed/changed a bit since that email). Unfortunately, I did not
> state the resultant behaviour I was looking to achieve (the above), just
> the changes to the protocol that would result in this behaviour.
>

That's from the PoV of Introduction Points. On the other hand, a
client that knows the onion address of an HS (or an HSDir before
https://lists.torproject.org/pipermail/tor-dev/2013-October/005534.html
gets implemented) can still get the list of all IPs (at least with the
current directory design). If some of the "HS peers" that correspond
to those IPs are down, then a client can notice this by sending
INTRODUCE1 cells to all the IPs and seeing which ones fail.

As a more conditional attack (from the IP PoV), let's think of a
super-HS with two "HS peers" where each of them has one Introduction
Point. If one of the "HS peers" goes down, then the other IP might be
able to figure this out using the number of introduction it conducts
(if we assume that each IP used to do half of the introductions of the
HS, then the number of introductions will increase when one "HS peer"
goes down.)

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev