[tor-dev] Hidden Service Scaling

[Christopher Baines]

On 02/05/14 00:45, waldo wrote:
> El 30/04/14 17:06, Christopher Baines escribió:
>> On 08/10/13 06:52, Christopher Baines wrote:
>>> I have been looking at doing some work on Tor as part of my degree, and
>>> more specifically, looking at Hidden Services. One of the issues where I
>>> believe I might be able to make some progress, is the Hidden Service
>>> Scaling issue as described here [1].
>>>
>>> So, before I start trying to implement a prototype, I thought I would
>>> set out my ideas here to check they are reasonable (I have also been
>>> discussing this a bit on #tor-dev). The goal of this is two fold,  to
>>> reduce the probability of failure of a hidden service and to increase
>>> hidden service scalability.
>> Previous threads on this subject:
>>   https://lists.torproject.org/pipermail/tor-dev/2013-October/005556.html
>>   https://lists.torproject.org/pipermail/tor-dev/2013-October/005674.html
>>
>> I have now implemented a prototype, for one possible design of how to
>> allow distribution in hidden services. While developing this, I also
>> made some modifications to chutney to allow for the tests I wanted to
>> write.
>>
>> In short, I modified tor such that:
>>   - The services public key is used in the connection to introduction
>> points (a return to the state as of the v0 descriptor)
>>   - multiple connections for one service to an introduction point is
>> allowed (previously, existing were closed)
>>   - tor will check for a descriptor when it needs to establish all of its
>> introduction points, and connect to the ones in the descriptor (if it is
>> available)
>>   - Use a approach similar to the selection of the HSDir's for the
>> selection of new introduction points (instead of a random selection)an
>> taack involvin
> 
>>   - Attempt to reconnect to an introduction point, if the connection
>> is lost
> I appreciate your work since Hidden services are really bad. Hard to
> reach ATM sometimes. But ... how you do this in details? Sorry but
> walking over your sources could be challenging if I don't know the
> original codebase you used and is gonna take more time than if I just
> ask you. I also can't test as I don't have enough resources/know how/time.

In terms of the code, just when the circuit to an introduction point has
failed, try to establish another one. I am unsure if I have taken the
best approach in terms of code, but it does seem to work.

>  I am worried about an attack coming from evil IP based on forced
> disconnection of the HS from the IP. I don't know if this is possible
> but I am worried that if you pick a new circuit randomly could be highly
> problematic. Lets say I am NSA and I own 10% of the routers and
> disconnecting your HS from an IP I control, if you select a new circuit
> randomly, even if the probabilities are low, eventually is a matters of
> time until I force you to use an specific circuit from those convenient
> to me in order to have a possible circuit(out of many) that transfers
> your original IP as metadata through cooperative routers I own and then
> do away with the anonymity of the hidden service.

Yeah, that does appear plausible. Are there guard nodes used for hidden
service circuits (I forget)?

>  The big question I have is what is the probability with current Tor
> network size of this happening? If things are like I describe, is a
> matter of seconds or thousand of years?

I am unsure. I implemented this, as it was quite probable when testing
with a small network using chutney. When testing the behaviour of the
network when an introduction point fails, you need to have reconnection,
otherwise instances which connect to other introduction points through
that failed introduction point, will also see those working introduction
points as failing. Leading to the instances using different introduction
points (what I was trying to avoid).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140502/bdb9810f/attachment.sig>