Hi, all!
I noticed that proposal 236 doesn't mention directory guards. (See proposal 207, implemented in Tor 0.2.4.) I think that we should consider retaining multiple directory guards while going to a single guard for multi-hop circuits.
My rationale here is that when we have only a single directory guard, it can more easily perform hard-to-detect route biasing attacks by pretending not to have descriptors for nodes it doesn't like. Its ability to do this is limited by fact that we won't build circuits unless 95% of all paths are buildable (see get_frac_paths_needed_for_circuits() and its users). But still, trusting a single source for the completeness and freshness of your directory info is suboptimal.
I also think that most of the arguments for single-guard apply to circuit guards more than to directory guards. But there could be some left, and we should figure those out.
peace,
On Mon, May 5, 2014 at 12:07 PM, Nick Mathewson nickm@torproject.org wrote:
I noticed that proposal 236 doesn't mention directory guards. (See proposal 207, implemented in Tor 0.2.4.) I think that we should consider retaining multiple directory guards while going to a single guard for multi-hop circuits.
...
I also think that most of the arguments for single-guard apply to circuit guards more than to directory guards. But there could be some left, and we should figure those out.
I think I mostly agree that having multiple directory guards should not be as significant a threat as multiple circuit guards. But: - Having directory guard(s) besides the circuit guard *will* increase vulnerability to guard fingerprinting, as in #10969 and https://lists.torproject.org/pipermail/tor-dev/2013-September/005424.html
- My directory guard knows when I'm using Tor, and so will be in a position to conduct long-term intersection attacks against sites with public logs or timestamps (e.g: IP w.x.y.z is always online when "SecretHandle" tweets). Having more guards increases vulnerability to this kind of attack. Would it make sense to relay directory requests through circuit guards to avoid this?
Nicholas Hopper hopper@cs.umn.edu writes:
On Mon, May 5, 2014 at 12:07 PM, Nick Mathewson nickm@torproject.org wrote:
I noticed that proposal 236 doesn't mention directory guards. (See proposal 207, implemented in Tor 0.2.4.) I think that we should consider retaining multiple directory guards while going to a single guard for multi-hop circuits.
...
I also think that most of the arguments for single-guard apply to circuit guards more than to directory guards. But there could be some left, and we should figure those out.
I think I mostly agree that having multiple directory guards should not be as significant a threat as multiple circuit guards. But:
- Having directory guard(s) besides the circuit guard *will* increase
vulnerability to guard fingerprinting, as in #10969 and https://lists.torproject.org/pipermail/tor-dev/2013-September/005424.html
- My directory guard knows when I'm using Tor, and so will be in a
position to conduct long-term intersection attacks against sites with public logs or timestamps (e.g: IP w.x.y.z is always online when "SecretHandle" tweets). Having more guards increases vulnerability to this kind of attack. Would it make sense to relay directory requests through circuit guards to avoid this?
FWIW, I've been using Tor with NumEntryGuards set to 1 for the past few days. The results are good: Tor sticks with its primary guard (the first guard in the entry guard list). However because my primary guard is not a DirCache, it has to use a separate relay as a directory mirror.
So, every few hours, Tor connects to a different relay (my dirguard: the second node in my guard list) to fetch descriptors etc. This is not a very big concern, but it's annoying for the reasons you mentioned above.
That made me curious to learn how many guard nodes are not directory servers. Apparently, out of all 5393 routers, we have 2149 guards, and 1458 guards that are directory servers. So there are about 700 guards that are _not_ directory servers (I wonder what their bandwidth weight is).
Apparently, this happens because the DirPort torrc option is required to be a directory server, and some relay operators just don't have it. Maybe we should consider again making all relays (or guards) to be directory servers. AFAIK, this idea was discarded in the past because it's not polite to open more ports (DirPort) on people's computers; but nowadays with BEGIN_DIR, we don't even need that extra port, right? Or maybe the reason is that directory documents take hard disk space? But how much space do they take? Probably not that much.
At the very least, maybe we should add a log message saying "You are a guard but not a directory server. You can increase the security of your clients by enabling the DirPort option.".
On Fri, Jun 6, 2014 at 10:07 AM, George Kadianakis desnacked@riseup.net wrote:
That made me curious to learn how many guard nodes are not directory servers. Apparently, out of all 5393 routers, we have 2149 guards, and 1458 guards that are directory servers. So there are about 700 guards that are _not_ directory servers (I wonder what their bandwidth weight is).
I wrote a script to compute this when Nickm first raised the question: $ python guard_dir_check.py ~/.tor/cached-microdesc-consensus 0 Total guard BW: 7083153.3967 Non-V2Dir guard BW: 1093535.0598
So, by weight it's a little lower - there's around 15% chance to choose a guard that's not a directory mirror atm. If you raise the advertised bandwidth threshold for guard relays to 2000, the answer stays about the same:
$ python guard_dir_check.py ~/.tor/cached-microdesc-consensus 2000 Total guard BW: 6750465.194 Non-V2Dir guard BW: 967363.393
Apparently, this happens because the DirPort torrc option is required to be a directory server, and some relay operators just don't have it. Maybe we should consider again making all relays (or guards) to be directory servers. AFAIK, this idea was discarded in the past because it's not polite to open more ports (DirPort) on people's computers; but nowadays with BEGIN_DIR, we don't even need that extra port, right?
I think this is right.
Or maybe the reason is that directory documents take hard disk space? But how much space do they take? Probably not that much.
The relay needs to have all of these documents in any case, right?
At the very least, maybe we should add a log message saying "You are a guard but not a directory server. You can increase the security of your clients by enabling the DirPort option.".
This would make sense, but note that nothing in the config file tells a relay that it's a guard. So it won't notice this without looking for its entry in the network status.
Nick Mathewson nickm@torproject.org writes:
Hi, all!
I noticed that proposal 236 doesn't mention directory guards. (See proposal 207, implemented in Tor 0.2.4.) I think that we should consider retaining multiple directory guards while going to a single guard for multi-hop circuits.
My rationale here is that when we have only a single directory guard, it can more easily perform hard-to-detect route biasing attacks by pretending not to have descriptors for nodes it doesn't like. Its ability to do this is limited by fact that we won't build circuits unless 95% of all paths are buildable (see get_frac_paths_needed_for_circuits() and its users). But still, trusting a single source for the completeness and freshness of your directory info is suboptimal.
Hi, all!
I noticed that proposal 236 doesn't mention directory guards. (See proposal 207, implemented in Tor 0.2.4.) I think that we should consider retaining multiple directory guards while going to a single guard for multi-hop circuits.
My rationale here is that when we have only a single directory guard, it can more easily perform hard-to-detect route biasing attacks by pretending not to have descriptors for nodes it doesn't like. Its ability to do this is limited by fact that we won't build circuits unless 95% of all paths are buildable (see get_frac_paths_needed_for_circuits() and its users). But still, trusting a single source for the completeness and freshness of your directory info is suboptimal.
I discussed this a bit with Roger yesterday, who helped me understand the issue.
It seems to me that from a security prespective it makes sense to use our circuit guard as our directory guard (assuming that it's a DirCache). This is to minimize our network fingerprint, and we also trust our guard to not selectively deny EXTEND requests anyway (which is a form of a path bias attack).
So, IIUC, the path bias attack Nick is worrying about is: a) Client fetches consensus from dirguard.
b) Client walks consensus and asks the dirguard for router microdescriptors in batches.
c) The attack is that a dirguard can now selectively claim that it doesn't have some microdescriptors, in an attempt to influence the path selection of the client.
The attack is not a big problem in the current architecture, since the client will go ahead and ask another directory guard for the missing descriptors. However, it becomes a problem when we have a single directory guard since there is no one else to talk to.
IIUC, the problem stems from the fact that even honest directory servers might not have the microdescriptors that a client asks for:
This might happen when a dirserv fetches a new consensus from the auths, the new consensus contains some unknown routers, and the dirserver hasn't fetched the descriptors for these unknown routers yet. So there is a race condition between the dirserv fetching a consensus, and the dirserv downloading all the missing descriptors, during which it will serve a consensus containing routers that it doesn't have the descriptors for.
Are there other legitimate cases where an honest directory server can claim to not have a descriptor?
If the above is the only case, we can fix it by making sure that directory servers start serving a consensus _only after_ they have downloaded the descriptors of all the routers mentioned in that consensus.
If the above behavior is applied, it means that honest directory servers don't have any excuse for not having a descriptor mentioned in a consensus they just served. Hence, a directory server that claims that, is an evil directory server.
But that's too easy, isn't it? I wonder how the above idea interacts when multiple consensuses are valid at the same time. And also if the above idea gets implemented, non-upgraded directory servers will be flagged as evil by upgraded clients.
.oO(I wonder how frequent it is for an honest dirguard to not have the descriptors a client is asking for.)
On Thu, Jun 5, 2014 at 12:50 PM, George Kadianakis desnacked@riseup.net wrote:
Nick Mathewson nickm@torproject.org writes:
Hi, all!
I noticed that proposal 236 doesn't mention directory guards. (See proposal 207, implemented in Tor 0.2.4.) I think that we should consider retaining multiple directory guards while going to a single guard for multi-hop circuits.
My rationale here is that when we have only a single directory guard, it can more easily perform hard-to-detect route biasing attacks by pretending not to have descriptors for nodes it doesn't like. Its ability to do this is limited by fact that we won't build circuits unless 95% of all paths are buildable (see get_frac_paths_needed_for_circuits() and its users). But still, trusting a single source for the completeness and freshness of your directory info is suboptimal.
Hi, all!
I noticed that proposal 236 doesn't mention directory guards. (See proposal 207, implemented in Tor 0.2.4.) I think that we should consider retaining multiple directory guards while going to a single guard for multi-hop circuits.
My rationale here is that when we have only a single directory guard, it can more easily perform hard-to-detect route biasing attacks by pretending not to have descriptors for nodes it doesn't like. Its ability to do this is limited by fact that we won't build circuits unless 95% of all paths are buildable (see get_frac_paths_needed_for_circuits() and its users). But still, trusting a single source for the completeness and freshness of your directory info is suboptimal.
I discussed this a bit with Roger yesterday, who helped me understand the issue.
It seems to me that from a security prespective it makes sense to use our circuit guard as our directory guard (assuming that it's a DirCache). This is to minimize our network fingerprint, and we also trust our guard to not selectively deny EXTEND requests anyway (which is a form of a path bias attack).
So, IIUC, the path bias attack Nick is worrying about is: a) Client fetches consensus from dirguard.
b) Client walks consensus and asks the dirguard for router microdescriptors in batches.
c) The attack is that a dirguard can now selectively claim that it doesn't have some microdescriptors, in an attempt to influence the path selection of the client.
That's the idea.
We should also reconsider the way that compute_frac_paths_available should work in a 1-guard world. Do we want to keep the requirement as "don't build circuits until you have the microdescriptors necessary to build X% of the paths through the network?" Or should we change it to require X% of all paths _through your guard_? Or raise the X?
The attack is not a big problem in the current architecture, since the client will go ahead and ask another directory guard for the missing descriptors. However, it becomes a problem when we have a single directory guard since there is no one else to talk to.
IIUC, the problem stems from the fact that even honest directory servers might not have the microdescriptors that a client asks for:
This might happen when a dirserv fetches a new consensus from the auths, the new consensus contains some unknown routers, and the dirserver hasn't fetched the descriptors for these unknown routers yet. So there is a race condition between the dirserv fetching a consensus, and the dirserv downloading all the missing descriptors, during which it will serve a consensus containing routers that it doesn't have the descriptors for.
Are there other legitimate cases where an honest directory server can claim to not have a descriptor?
Maybe it can't get it from the authorities for some reason. (Like, when it tried to fetch descriptors, one download failed, and it hasn't retried yet. Or it asked an authority that doesn't know about a given microdescriptor yet (because the authority didn't vote for that one), and it hasn't retried yet.
If the above is the only case, we can fix it by making sure that directory servers start serving a consensus _only after_ they have downloaded the descriptors of all the routers mentioned in that consensus.
In spite of what I say below, this behavior or something like might actually be a good idea. (needs-proposal.)
If the above behavior is applied, it means that honest directory servers don't have any excuse for not having a descriptor mentioned in a consensus they just served. Hence, a directory server that claims that, is an evil directory server.
But that's too easy, isn't it?
I think so. It would break an assumption in our current directory model, and breaking assumptions like that (that directories are allowed to not know things) make me a bit nervous. Also, as you note below, clients wouldn't be able to rely on it until every directory guard has updated.
I wonder how the above idea interacts when multiple consensuses are valid at the same time. And also if the above idea gets implemented, non-upgraded directory servers will be flagged as evil by upgraded clients.
.oO(I wonder how frequent it is for an honest dirguard to not have the descriptors a client is asking for.)
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Thu, Jun 05, 2014 at 01:26:09PM -0400, Nick Mathewson wrote:
It would break an assumption in our current directory model, and breaking assumptions like that (that directories are allowed to not know things) make me a bit nervous.
I wonder if that ship already sailed when we moved to the directory guards design -- if directories are allowed to not know things, but you pick only a few and ask only them, then they'd best know everything you need.
--Roger
-
George Kadianakis -
Nicholas Hopper -
Nick Mathewson -
Nick Mathewson -
Roger Dingledine