Opened 6 years ago

Closed 4 years ago

Last modified 4 years ago

#8243 closed enhancement (fixed)

Getting the HSDir flag should require the Stable flag

Reported by: arma Owned by:
Priority: High Milestone: Tor: 0.2.7.x-final
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Keywords: tor-auth, needs-proposal, 026-triaged-1, 027-triaged-1-in, SponsorU, 026-backport
Cc: rpw, amj703, dgoulet, teor Actual Points:
Parent ID: #16538 Points: medium
Reviewer: Sponsor: SponsorR

Description

When we invented the HSDir flag, our goal was to only use nodes for storing hidden service descriptors if they're likely enough to be around later. The question was solely around robustness: pick all but the nodes that have a good chance of going away while your hidden service descriptor is valid. We picked "has 25 hours of uptime" as what we hoped was an adequate threshold to stand in for the real question, which is "will likely remain online for the next hour".

But actually, there are security implications here too: an adversary who can control all six hsdir points for a hidden service can censor it (or, less bad, observe how many anonymous people access it).

So we should raise the bar for getting the HSDir flag, to raise the cost to an adversary who tries the Sybil the network in order to control lots of HSDir points.

That said, there's a contradiction here: the more restrictive we are about who gets the HSDir flag, the more valuable it becomes to get it. At the one extreme (our current choice), we give it to basically everybody, so you have to get a lot of them before your attack matters. At the other extreme, we could give it to our favorite 20 relays, and if we choose wisely then basically no adversaries will get the HSDir flag. What are the sweet spots in between?

(This ticket is inspired by rpw's upcoming Oakland paper)

Child Tickets

Change History (35)

comment:1 Changed 6 years ago by arma

One of the first steps here is probably to do more checking of uptime than "what does the descriptor say?" The directory authorities have internal statistics of up segments and down segments, as measured by actual reachability tests, but we don't use them currently when allocating HSDir flags.

comment:2 Changed 6 years ago by arma

We might also want some minimum bandwidth requirement. But given that our active bandwidth measurement tools aren't really fool-proof to an attacker trying to game them, and discarding some otherwise honest nodes from the list would make the remaining nodes even higher-value, I am hesitant to go very far down this path.

That said, requiring the 'Fast' flag would probably be a reasonable step.

comment:3 Changed 6 years ago by arma

When it comes to actually increasing cost to an attacker... how about something like "has been an Exit relay with some minimum WFU over the past week"?

I bet that would cut down on researchers using Amazon cloud to Sybil the Tor network. But it probably wouldn't cut down on botnet operators doing a real attack.

So I suspect it falls into the 'cute trick that works in an academic paper setting but is not really a robust security measure' bucket, alas.

Are there any cute tricks like this that are more robust to real attackers?

comment:4 in reply to:  2 Changed 6 years ago by cypherpunks

We might also want some minimum bandwidth requirement. But given that our active bandwidth measurement tools aren't really fool-proof to an attacker trying to game them

Active bandwidth measurement is better than no bandwidth measurement at all.

That said, requiring the 'Fast' flag would probably be a reasonable step.

'Fast' flag do not costs anything for attacker if no any bandwidth measurement. You shouldn't count such requirement with current zero bandwidth measurement.

comment:5 Changed 6 years ago by hsn

what about to require Stable Flag and no more then 1 tor node per network segment.

comment:6 Changed 6 years ago by hsn

make it 10 mbit and Guard

comment:7 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

comment:8 Changed 5 years ago by naif

I suggest a different formula.

What if Tor Relay that can became HSDir only if:

  • that are part of a Family of at least X nodes
  • that have an uptime of at least Y months
  • that are pushing at least K MBit/s of traffic

The "Big families" of Tor Relay are all run by "known" and "trustable" organizations (TorServers-alike).

The "Big families" of Tor Relay are clearly visible in the consensus, they cannot just start to exists from one day to another one without being noticed.

By using that approach the HSDir will be de-facto managed only by "Organizations that contribute to Tor network", that can be identified.

No easy rough or "hidden" nodes will be able to became HSDir.

Last edited 5 years ago by naif (previous) (diff)

comment:9 in reply to:  8 Changed 5 years ago by special

Replying to naif:

What if Tor Relay that can became HSDir only if:

  • that are part of a Family of at least X nodes
  • that have an uptime of at least Y months
  • that are pushing at least K MBit/s of traffic

The "Big families" of Tor Relay are all run by "known" and "trustable" organizations (TorServers-alike).

By using that approach the HSDir will be de-facto managed only by "Organizations that contribute to Tor network", that can be identified.

You should realize at the phrase "the HSDir will be de-facto managed ... by organizations" that this is a bad idea. I would rather trust a large number of unknown people to be in sum honest and uncorrupted. These organizations would be able to, by consensus or legal action, censor or track hidden services.

That is similar to the situation with version 1 of the hidden service spec, where authorities managed the HSDir.

comment:10 Changed 5 years ago by nickm

Keywords: 026-triaged-1 added

comment:11 Changed 5 years ago by arma

Keywords: SponsorR added

comment:12 Changed 5 years ago by arma

Cc: amj703 added

comment:13 Changed 4 years ago by dgoulet

Cc: dgoulet added

comment:14 Changed 4 years ago by teor

Cc: teor added

comment:15 Changed 4 years ago by nickm

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

comment:16 Changed 4 years ago by asn

It seems that most realistic attacks on HSDirs will be plugged by introducing non-deterministic HSDir selection (#8244) and keyblinding (#8106).

This ticket though could help against attacks by less sophisticated adversaries. For example by making the HSDir flag a bit harder to get, we can defend against weaker adversaries like the lizards or people who bruteforce their relay's public key to become the HSDir of hidden services and then measure their popularity. Roger suggested that HSDir flag should only be given to Stable relays, and this might be a sane idea.

Looking at metrics, this will half the number of HSDirs from 3k down to 1.5k. The number is still big enough and getting Stable flag requires a week, which means that it will give us time to !reject big sybil attacks.

Maybe more thought needs to be given here, but making it harder to become an HSDir flag seems to be a good idea.

comment:17 Changed 4 years ago by asn

Another argument for having Stable be a prerequisite of HSDir is that when we get the shared randomness feature, the main way for an adversary to camp all 6 HSDirs of an HS would be to flood the network with HSDirs. This is made harder if the adversary also needs to get the Stable flag, so it seems like this change also has long-term benefits.

comment:18 Changed 4 years ago by nickm

Status: newassigned

comment:19 Changed 4 years ago by asn

Another argument by dgoulet is that by requiring the Stable flag, we make it more unlikely to have descriptor fetch failures because of natural churn.

comment:20 in reply to:  19 Changed 4 years ago by special

Replying to asn:

Another argument by dgoulet is that by requiring the Stable flag, we make it more unlikely to have descriptor fetch failures because of natural churn.

We also reduce churn in the list of HSDirs, which seems like a good thing.

I wonder if having only stable HSDirs might allow us to switch from 6 HSDirs to n<6 HSDirs in the future.

comment:21 Changed 4 years ago by nickm

Keywords: 027-triaged-1-in added

Marking some tickets as triaged-in for 0.2.7 based on early triage

comment:22 Changed 4 years ago by isabela

Keywords: SponsorU added
Points: medium
Priority: normalmajor
Version: Tor: 0.2.7

comment:23 Changed 4 years ago by dgoulet

Status: assignedneeds_review

Simple patch on tor and torspec for HSDir to require the Stable flag.

Tor branch: bug8243_027_01
Torspec branch: ticket8243_01

comment:24 Changed 4 years ago by yawning

Keywords: 026-backport added

Code looks ok, dunno about the gratuitous newline removal.

I'll tag it for potential 026-backport per IRC discussion, since making it hard to Sybil is a good thing, and if implemented this should go into the version that's run by most DirAuths (0.2.6.x). If people disagree, remove the tag.

comment:25 Changed 4 years ago by nickm

I think looking at node->is_stable might be incorrect. That makes us look at the node's stability value form the _last_ consensus, right? (Or did we just go through all the node_t objects and set that?)

comment:26 in reply to:  25 ; Changed 4 years ago by dgoulet

Replying to nickm:

I think looking at node->is_stable might be incorrect. That makes us look at the node's stability value form the _last_ consensus, right? (Or did we just go through all the node_t objects and set that?)

It's set in set_routerstatus_from_routerinfo() which set both the routerstatus_t and node_t variable is_stable at the same time.

Few line after, dirserv_thinks_router_is_hs_dir() is called so it seems that using node->is_stable in that function will give us the latest status we have on that relay.

comment:27 in reply to:  26 Changed 4 years ago by asn

Replying to dgoulet:

Replying to nickm:

I think looking at node->is_stable might be incorrect. That makes us look at the node's stability value form the _last_ consensus, right? (Or did we just go through all the node_t objects and set that?)

It's set in set_routerstatus_from_routerinfo() which set both the routerstatus_t and node_t variable is_stable at the same time.

Few line after, dirserv_thinks_router_is_hs_dir() is called so it seems that using node->is_stable in that function will give us the latest status we have on that relay.

That seems right.

Patch looks correct in general, but it still uses the MinUptimeHidServDirectoryV2 uptime check . Do we still want that check in? In prop243 I suggested we remove it, but I could be convinced otherwise.

Also, since we didn't remove the other check, and we just added another constraint, how could the number of HSDirs increase as the changes file claims? Finally, probably in the changes file I would write something like "Make it harder to launch Sybil attacks by ..." so that it gives some rationale for our action.

comment:28 Changed 4 years ago by yawning

After discussion in #tor-dev today, we've decided to keep both checks and also implement #15963 (HSDirs must also be Fast) while we're at this. Unless something unexpected comes up this should be in the next 0.2.6.x release.

comment:29 Changed 4 years ago by dgoulet

Ok the changes file has been fixed with the latest numbers and addition from asn's comment.

Branch: bug8243_027_02
Torspec branch: ticket8243_01 (unchanged)

comment:30 Changed 4 years ago by dgoulet

My mistake, here is the 026 branch: bug8243_026_01

comment:31 Changed 4 years ago by nickm

Merged to 0.2.6 and forward. Can't close this ticket while child is open.

comment:32 in reply to:  31 Changed 4 years ago by dgoulet

Resolution: fixed
Status: needs_reviewclosed

Replying to nickm:

Merged to 0.2.6 and forward. Can't close this ticket while child is open.

I removed the parend ID from the child ticket so we can close this along with an explanation on why.

comment:33 Changed 4 years ago by arma

Summary: Getting the HSDir flag should require more effortGetting the HSDir flag should require the Stable flag

(renaming ticket to be more narrow, to match what we actually did)

comment:34 Changed 4 years ago by arma

Parent ID: #16538

comment:35 Changed 4 years ago by dgoulet

Keywords: SponsorR removed
Sponsor: SponsorR
Note: See TracTickets for help on using tickets.