[tor-dev] Hidden Service Scaling

[Christopher Baines]

On 04/05/14 11:43, waldo wrote:
> El 02/05/14 02:34, Christopher Baines escribió:
>> On 02/05/14 00:45, waldo wrote:
>>>   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)?
> No idea, according to this docs
> https://www.torproject.org/docs/hidden-services.html.en there aren't
> guards in the circuits to the IP in step one(not mentioned). They are
> definitely used on step five to protect against a timing attack with a
> corrupt entry node.
> 
>  Even if they are used, I still see some problems. I mean it looks
> convenient to try to reconnect to the same IP but in real life you are
> going to find nodes that fail a lot so if you picked an IP that has bad
> connectivity reconnecting to it is not gonna contribute at all with the
> HS scalability or availability of your HS, on the contrary.

I don't think a minority of bad IP's will do much to hurt a hidden
service. Clients will try connecting through all IP's until giving up,
and this will only happen when they initially connect.

>  Maybe a good idea would be to try to reconnect and if it is failing too
> much select another IP.

It currently does do this, but on probably a shorter time period than
you are suggesting. It keeps a count of connection failures while trying
to reconnect, but this is reset once a new connection is established.

This gets complicated, as you need to ensure that each instance of the
service is using the same introduction points, it seems to me that
tracking connectivity failures over the long term, and changing IP on
some threshold could break this.

> If the IP is doing it on purpose the HS Is going to go away so the
> control the IP has disconnecting your HS is capped for any attack known
> or unknown. If is not on purpose the HS goes throwing away failing nodes
> until it picks a good node as IP. I think it would cause over time, the
> tor network re-balance/readapt to new conditions itself. For instance in
> the case some IP is overloaded (maybe by DoS) causes the HS to go away
> from the IP.
> 
> I would also rotate the IPs after using them some time. I don't think is
> good to have one IP for too long. Doesn't sounds good to me. If for
> instance I am big daddy and know your IPs I could go there seize the
> computers and start gathering funny statistics about your HS. Or simply
> censor your HS by dropping messages from clients trying to send you the
> rendezvous point (is this possible? looks like it is if I drop introduce
> messages and generate fake ones). You wouldn't even know cause I can
> keep your connected and receiving fake connections. Only maybe if you
> try to check the IP by trying to send a rendezvous point from your HS to
> your HS (this IP quality test would be great if tor would do it
> periodically). I somehow do it myself manually  when I notice the HS is
> superhard to reach. Sometimes it works great, sometimes even being
> turned on the server and online, is not visible. So you have to take
> down tor and restart it and wait again for a while.
> 
> I was thinking maybe you could select new ones and inform HSDirs about
> the change and after the new ones are known end circuits to the previous
> IPs and with that avoid the overhead of the rotation.
> 
>  I would rebuild circuits to the IP from time to time (originating from
> the HS). Multiple connections to the same IP would permit to do this
> better since I can make a new one and afterwards kill a previous circuit
> remaining connected all the time.

Lots of things here, generally, some things seem quite hard to do in a
uncoordinated, distributed manor (e.g. IP rotation). And I am not to
sure that things like IP rotation and rebuilding circuits to IP's will
even help with anonymity issues.

> In some previous messages about the subject I saw that HSDirs provide
> all the HS IPs. I don't like this way of doing things since let's say I
> have 6 IPs to my HS available to everyone. To cause a DoS to your HS
> seems to me all I have to do is cause a DoS to the IPs. And there is no
> need for everyone to know all the IPs of one HS all the time. All one
> user needs to connect is just some maybe for redundancy but not all.
> 
> Is there some way to only provide part of the IPs of one HS to one user?
> Avoid enumeration? Maybe distribute partial information to HSDirs? Don't
> know, just thinking. Maybe "abuse" some caching effect on HSDirs and
> publish partial IP information on one end and partial in another end
> that only reaches all users in entirety over time.

As the set of IP's is so small, I cannot think of any practical way to
do this without it being trivial to break.

-------------- 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/20140504/0c6a03cf/attachment-0001.sig>