Opened 5 years ago

Closed 5 years ago

#15714 closed defect (fixed)

Don't always ditch intro point after 16384 introductions

Reported by: asn Owned by:
Priority: Medium Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-hs
Cc: s7r Actual Points:
Parent ID: Points:
Reviewer: Sponsor: SponsorR


We should rethink the value and behavior of INTRO_POINT_LIFETIME_INTRODUCTIONS.

Currently, it's set to 16384 which means that an HS will rotate the intro point after it has performed 16384 introductions. This is bad for a few reasons:
a) An attacker can intentionally hit that limit faster than the normal lifetime of intro points (18 to 24 hours)
b) The number is static, which means that an attacker can count the number of intros required to rotate the intro point to gauge the popularity of a hidden service.
c) It's probably too small for busy hidden services.

We should rethink this behavior. We should probably change the value 16384, and also randomize it slightly.

We don't really know how to get a better value here but we could ponder on statistics that would help us. Also, whatever the new value is maybe we should make it configurable and have a notice-level log message when it's reached so that HS operators can increase if it happens too often.

Child Tickets

#15744closedIs 16384 introductions a sane limit for IP rotation?Core Tor/Tor
#15745closedRandomize the introduction point accepted INTRODUCE2 countCore Tor/Tor
#15746closedAdd a torrc option to set the value of INTRODUCE2 cells seen before rotating an intro pointCore Tor/Tor

Change History (9)

comment:1 Changed 5 years ago by nickm

One reason this value exists is so that the replay cache doesn't have to grow without bound.

comment:2 Changed 5 years ago by dgoulet

Keeping the value is important for both the replay cache size (like nickm mentionned) and being able to also balance load of IPs over the network. My thought is to use a random value in a large enough interval to avoid too small values that would be easy to manipulate leaking popularity.

For the interval, I propose we use by default 16384 as the minimum value and maximum would be double that. I currently have no idea how we can end up finding the perfect value for this apart from having secure statistics so for now let's go with what we have and improve it with randomness.

Basically: random([16384, 32768])

I agree that we could also introduce a torrc option for an operator to be able to set that minimum value in case of high load but I think we shouldn't allow it to go below this default else we might end up in some operators exchanging configuration with a value of let say 8 and that would put a load on the network for not much more safety...

comment:3 Changed 5 years ago by dgoulet

Status: newneeds_review

I really want this to go forward so I've made a patch for the random value part. If we decide to make a torrc option to control the minimum value, we should do that maybe in another ticket.

little-t tor code branch: bug15714_027_01

comment:4 Changed 5 years ago by nickm

Code looks correct if we decide to do this. It solves issue b, but doesn't address a or c ... yet it could be the start of a decent thing for those.

I almost want to have crypto.c define a new function crypto_rand_int_range(low,high) to capture the pattern that this RNG code uses.

comment:5 Changed 5 years ago by nickm

Status: needs_reviewnew

We merged the subticket #15745 ; this is no longer needs_review.

comment:6 Changed 5 years ago by dgoulet

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

comment:7 Changed 5 years ago by s7r

Cc: s7r added

comment:8 Changed 5 years ago by nickm

Keywords: SponsorR removed
Sponsor: SponsorR

Bulk-replace SponsorR keyword with SponsorR sponsor field in Tor component.

comment:9 Changed 5 years ago by asn

Resolution: fixed
Status: newclosed

All child tickets closed and I think we are happy with the current state of this feature.

Note: See TracTickets for help on using tickets.