[tor-dev] Hidden Service Scaling

Christopher Baines cbaines8 at gmail.com
Wed May 7 16:32:29 UTC 2014


On 07/05/14 13:51, Michael Rogers wrote:
> On 06/05/14 22:17, Christopher Baines wrote:
>> If so, then yes. When I implemented the deterministic selection of 
>> introduction points, I had to implement a reconnection mechanism
>> to ensure that the introduction point would only be changed if it
>> had failed, and not in the case of intermittent network issues (the
>> degree to which I have actually done this might vary).
> 
> Is it necessary to know why the circuit broke, or is it sufficient to
> try rebuilding the circuit, and pick a new IP if the old one isn't
> reachable?

I imagine that the service will still have to try connecting via an
alternate route, as even if it was told that the introduction point is
no longer available, it should still check anyway (to avoid being tricked).

> What about the attack suggested by waldo, where a malicious IP
> repeatedly breaks the circuit until it's rebuilt through a malicious
> middle node? Are entry guards enough to protect the service's
> anonymity in that case?

I think it is a valid concern. Assuming the attacker has identified
their node as an IP, and has the corresponding public key. They can then
get the service to create new circuits to their node, buy just causing
the existing ones to fail.

Using guard nodes for those circuits would seem to be helpful, as this
would greatly reduce the chance that the attackers nodes are used in the
first hop.

If guard nodes where used (assuming that they are currently not), you
would have to be careful to act correctly when the guard node fails, in
terms of using a different guard, or selecting a new guard to use
instead (in an attempt to still connect to the introduction point).

-------------- 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/20140507/b9fa2af4/attachment.sig>


More information about the tor-dev mailing list