Getting the HSDir flag should require the Stable flag
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)
Activity
changed milestone to %Tor: 0.2.7.x-final
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.
-
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.
-
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?
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.
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.
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.
It seems that most realistic attacks on HSDirs will be plugged by introducing non-deterministic HSDir selection (#8244 (moved)) and keyblinding (#8106 (moved)).
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.
-
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.
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.
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.
Trac:
Keywords: N/A deleted, 026-backport added
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 therouterstatus_tandnode_tvariableis_stableat the same time.Few line after,
dirserv_thinks_router_is_hs_dir()is called so it seems that usingnode->is_stablein that function will give us the latest status we have on that relay.-
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 therouterstatus_tandnode_tvariableis_stableat the same time.Few line after,
dirserv_thinks_router_is_hs_dir()is called so it seems that usingnode->is_stablein 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
MinUptimeHidServDirectoryV2uptime 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.
After discussion in #tor-dev today, we've decided to keep both checks and also implement #15963 (moved) (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.-
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.
Trac:
Status: needs_review to closed
Resolution: N/A to fixed -
Trac:
Parent: N/A to #16538 (moved) mentioned in issue #14034 (moved)
mentioned in issue #14055 (moved)
mentioned in issue #15963 (moved)
mentioned in issue #16524 (moved)
mentioned in issue #19162 (moved)
moved to tpo/core/tor#8243 (closed)
mentioned in issue tpo/core/tor#14034 (closed)
mentioned in issue tpo/core/tor#14055 (closed)
mentioned in issue tpo/core/tor#16524 (closed)
mentioned in issue tpo/core/tor#19162
