2d4507ff35
With this change, each individual identity type becomes optional. The functions that expose them unconditionally are now in a "legacy" trait that only some downstream types are expected to implement. There are new convenience APIs in HasRelayIds: * to return Option<&keytype>, * to see if one identity-set contains another. This commit will break several downstream crates! For the reviewer's convenience, I will put the fixes for those crates into a series of squash! commits on this one. tor-netdir ---------- Revise tor-netdir to accept optional identities. This required some caveats and workarounds about the cases where we have to deal with a key type that the tor-netdir code does not currently recognize at all. If we start to add more identity types in the future, we may well want more internal indices in this code. tor-proto --------- In order to make tor-proto support optional identities, there were fewer changes than I thought. Some "check" functions needed to start looking at "all the ids we want" rather than at "the two known IDs"; they also needed to accommodate that case where we don't have an ID that we demand. This change will also help with bridges, since we want to be able to connect to a bridge without knowing all of its IDs up front. The protocol currently _requires_ the two current ID types in some places. To deal with that, I added a new `MissingId` error. I also removed a couple of unconditional identity accessors for chanmgr; code should use `target().identity(...)` instead. tor-chanmgr ----------- This is an incomplete conversion: it does not at all handle channel targets without Ed25519 identities yet. It still uses those identities to index its internal map from identity to channel; but it gives a new `MissingId` error type if it's given a channel target that doesn't have one. We'll want to revise the map type again down the road when we implement bridges, but I'd rather not step on the channel-padding work in progress right now. tor-guardmgr ------------ This change is mostly a matter of constructing owned identity types more sensibly, rather than unwrapping them directly. There are some places marked with TODOs where we still depend on particular identity types, because of how the directory protocol works. This will need revisiting when we add bridge support here. tor-circmgr ----------- These changes are just relatively simple API changes in the tests. |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
| semver.md | ||
README.md
tor-guardmgr
tor-guardmgr: guard node selection for Tor network clients.
Overview
This crate is part of Arti, a project to implement Tor in Rust.
"Guard nodes" are mechanism that Tor clients uses to limit the impact of hostile relays. Approximately: each client chooses a small set of relays to use as its "guards". Later, when the client picks its paths through network, rather than choosing a different first hop randomly for every path, it chooses the best "guard" as the first hop.
This crate provides [GuardMgr], an object that manages a set of
guard nodes, and helps the tor-circmgr crate know when to use
them.
Guard nodes are persistent across multiple process invocations.
More Arti users won't need to use this crate directly.
Motivation
What's the point? By restricting their first hops to a small set, clients increase their odds against traffic-correlation attacks. Since we assume that an adversary who controls both ends of a circuit can correlate its traffic, choosing many circuits with random entry points will eventually cause a client to eventually pick an attacker-controlled circuit, with probability approaching 1 over time. If entry nodes are restricted to a small set, however, then the client has a chance of never picking an attacker-controlled circuit.
(The actual argument is a little more complicated here, and it relies on the assumption that, since the attacker knows statistics, exposing any of your traffic is nearly as bad as exposing all of your traffic.)
Complications
The real algorithm for selecting and using guards can get more complicated because of a variety of factors.
-
In reality, we can't just "pick a few guards at random" and use them forever: relays can appear and disappear, relays can go offline and come back online, and so on. What's more, keeping guards for too long can make targeted attacks against those guards more attractive.
-
Further, we may have particular restrictions on where we can connect. (For example, we might be restricted to ports 80 and 443, but only when we're on a commuter train's wifi network.)
-
We need to resist attacks from local networks that block all but a small set of guard relays, to force us to choose those.
-
We need to give good, reliable performance while using the guards that we prefer.
These needs complicate our API somewhat. Instead of simply asking
the GuardMgr for a guard, the circuit-management code needs to
be able to tell the GuardMgr that a given guard has failed (or
succeeded), and that it needs a different guard in the future (or
not).
Further, the GuardMgr code needs to be able to hand out
provisional guards, in effect saying "You can try building a
circuit with this guard, but please don't actually use that
circuit unless I tell you it's safe."
For details on the exact algorithm, see guard-spec.txt (link
below) and comments and internal documentation in this crate.
Limitations
- Our circuit blocking algorithm is simplified from the one that Tor uses.
See comments in
GuardSet::circ_usability_statusfor more information. See also proposal 337.
References
Guard nodes were first proposes (as "helper nodes") in "Defending Anonymous Communications Against Passive Logging Attacks" by Matthew Wright, Micah Adler, Brian N. Levine, and Clay Shields in the Proceedings of the 2003 IEEE Symposium on Security and Privacy. (See https://www.freehaven.net/anonbib/#wright03)
Tor's current guard selection algorithm is described in Tor's
guard-spec.txt
document.
License: MIT OR Apache-2.0