[tor-dev] Introduction Points and their rotation periods (was Re: Hidden Service Scaling)

[George Kadianakis]

waldo <waldoalvarez00 at yahoo.com> writes:

> El 02/05/14 02:34, Christopher Baines escribió:
>> 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].
>>>>>
>> <snip>
>>
>>>   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.
>

Hello waldo,

as far as I can tell, that circuit does use entry guards. And that's
good, because I think that an HS circuit that doesn't use entry guards
wouldn be bad news.

I think choose_good_entry_server() is used for all circuits, and if
guards are used, it picks an entry guard for all circuits (except from
the ones with purpose CIRCUIT_PURPOSE_TESTING) [0].

> <snip>
>
> 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

It's interesting that you say this, because we pretty much took the
opposite approach with guard nodes. That is, the plan is to extend
their rotation period to 9 months (from the current 2-3 months). See:
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/236-single-guard-node.txt

I was even planning on writing an extension to rend-spec-ng.txt to
specify how IPs should be picked and to extend their rotation
period. That's for the same reason we do it for entry guards:

We assume that it's preferrable to never get owned as long as you
picked good guards/IPs, than to surely get owned eventually but only
some of the time (and ownage _will_ occur if you frequently rotate
guards/IPs). The main argument for preferring the former behavior (at
least for guards), is that if the adversary can deanonymize you some
times it's likely that they can extrapolate to total ownage by using
statistics and behavior analysis (is this true?).

I admit that we didn't take much into consideration an adversary who
can lawfully seize boxes; mainly because it's hard to quantify such a
threat. For example, if a motivated attacker has that power, does it
make much difference if he has 2 months or 9 months to act? He can
probably "get a warrant" and seize the servers in hours/days if
needed.

Also note that even though it makes sense to say "these are different
behaviors that facilitate different threat models, and each user
should be able to select the behavior that suits her", it's not that
easy to support both behaviors because that will divide the anonymity
set.  Hm. At least that's true for guards, is it also true for HSes
and the rotation period of their IPs?

(For example, I think it's wise to assume that a motivated
deanonymizing HS attacker has access to the HS descriptor and hence to
the list of IPs. So maybe rotating IPs faster than other HSes doesn't
harm your anonymity set from this perspective... Don't know
really... This is hard stuff.)

PS: I changed the subject of this thread, because the thread was
    becoming immense and hard to dig through.

[0]:  
  if (state && options->UseEntryGuards &&
      (purpose != CIRCUIT_PURPOSE_TESTING || options->BridgeRelay)) {
    /* This request is for an entry server to use for a regular circuit,
     * and we use entry guard nodes.  Just return one of the guard nodes.  */
    return choose_random_entry(state);
  }