Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#2709 closed defect (fixed)

Relays can trick authorities into assigning the hsdir flag early

Reported by: Sebastian Owned by:
Priority: Medium Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-auth
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Dirauths trust the uptime value reported in a relay's descriptor instead of doing some checking of their own to see if the reported value is plausible.This means it is cheaper than expected to mount a dos attack against a known hidden service by targetting the nodes responsible for storing its descriptor.

Child Tickets

Change History (10)

comment:1 Changed 9 years ago by Sebastian

Status: newneeds_review

See branch hsdir_assignment in my repository for a suggested fix.

comment:2 Changed 9 years ago by nickm

I wonder whether this ought to use MTBF or WFU instead of mere uptime. WFU seems a little better: we want a node that will "probably be up and reachable", not "one that _has_ been up a long time."

But merging a fix here seems like a basically good idea. The DoS attack in question would take a bit of doing to mount (it's not just a matter of "announce a high uptime" but also "predict the future location in the ring of a hidden service you don't like, get yourself put close to it in the ring during that time, and run a set of nodes that are at a bare minimum Running and Valid with proper identity keys." Nonetheless, let's not leave the window open too long.

This approach will require a change to section 3.3 of dir-spec.txt, which was apparently incorrect before.

comment:3 Changed 9 years ago by nickm

Reviewing the patch:

  • I want to clarify the changes file to specify the attack a little more accurately.
  • I want to avoid a the possibility of negative uptimes.

I've pushed a tweak to a hsdir_assignment branch in my public repository.

Another security measure: perhaps the authorities should simply not allow more than N identities per IP per time-unit. If a router is frequently changing its identity, it's probably up to no good. Worth writing a proposal there.

comment:4 in reply to:  3 Changed 9 years ago by Sebastian

Replying to nickm:

Reviewing the patch:

  • I want to clarify the changes file to specify the attack a little more accurately.
  • I want to avoid a the possibility of negative uptimes.

I've pushed a tweak to a hsdir_assignment branch in my public repository.

The fixes look good to me.

Another security measure: perhaps the authorities should simply not allow more than N identities per IP per time-unit. If a router is frequently changing its identity, it's probably up to no good. Worth writing a proposal there.

I disagree here. New relay operators that experience some problem often wipe their keys frequently, and also people might share the same IP address if they get one assigned on the fly. I suppose this should be out of scope here, and be discussed in a proposal if it happens.

comment:5 Changed 9 years ago by arma

Looks like this patch doesn't conflict with #2088.

Also, it's worth noting that for clients and hidden services on Tor 0.2.1.x, they publish to and fetch from tor26 too, so an attacker would have to knock that one down too. Not really a reason to change our plan, but good to notice.

comment:6 Changed 9 years ago by arma

Patch looks good to me. I've been running it on moria1 for a little while, and nothing has exploded. Merge when you like. (I'm guessing we should merge into maint-0.2.2.)

comment:7 Changed 9 years ago by arma

Component: Tor RelayTor Directory Authority

comment:8 Changed 9 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Merged & closing.

comment:9 Changed 7 years ago by nickm

Keywords: tor-auth added

comment:10 Changed 7 years ago by nickm

Component: Tor Directory AuthorityTor
Note: See TracTickets for help on using tickets.