[tor-bugs] #19468 [Core Tor/Tor]: Revise prop259 to fit the Tor networking API
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Jul 18 07:00:29 UTC 2016
#19468: Revise prop259 to fit the Tor networking API
-------------------------------------------------+-------------------------
Reporter: asn | Owner: nickm
Type: defect | Status:
Priority: Medium | needs_revision
Component: Core Tor/Tor | Milestone: Tor:
Severity: Normal | 0.2.9.x-final
Keywords: tor-guard, TorCoreTeam201606, | Version:
prop259, TorCoreTeam201607 | Resolution:
Parent ID: #12595 | Actual Points: 5
Reviewer: | Points: 3
| Sponsor:
| SponsorU-must
-------------------------------------------------+-------------------------
Comment (by teor):
I'm not sure if there's a gitlab for this version, or if I should wait for
asn to make one.
Here are my comments:
'''ReachableAddresses is insufficient to model reachability'''
In [Section:FILTERED], we say that a member of FILTERED_GUARDS must have
the following property:
- It is not disabled because of ReachableAddress policy [XX??]
This works, but is not enough...
`ReachableAddresses` implicitly includes `FascistFirewall` and
`FirewallPorts` (which are merged into `ReachableAddresses` during options
processing anyway). We can also understand `ClientUseIPv4 0` and
`ClientUseIPv6 1` as part of `ReachableAddresses`: although the current
implementation doesn't actually merge them into `ReachableAddresses`, it
acts as if it does.
'''ReachableDirAddresses and Directory Guards'''
We don't appear to model the distinction between `ReachableDirAddresses`
and `ReachableORAddresses`. This doesn't matter for clients, because in
0.2.8 and later, clients only use begindir over ORPort for directory
fetches (see #19704 for a ticket to deprecate `ReachableDirAddresses` and
`ClientPreferIPv6DirPort`).
However, relays still choose directory guards for their fetches (ignoring
`ReachableDirAddresses`, because they are relays). But do they use them?
Some do, some just fetch straight from the authorities. But perhaps
they're unnecessary for a relay. Perhaps we should just abolish directory
guards entirely. (Almost all of a client's guards will cache directory
info once they upgrade to 0.2.8, and relays can just ask a relay with a
DirPort, or an authority.)
But does this open relays up to an attack where they eventually try a
malicious relay?
Should all relays just fetch from the authorities? (Or the fallback
directories?)
'''IP Version Preferences'''
There's no mention in the proposal of clients which can reach both IPv4
and IPv6 addresses, but prefer IPv6 addresses. We should use
`ClientPreferIPv6ORPort` to tell us whether to prioritise using guards
that support IPv6 over those that do not. [Section:FILTERED] would be a
good place for this. I'd say it like this:
- If ClientPreferIPv6ORPort is 1, and UseBridges is 0, it has an IPv6
ORPort
(this restriction must be ignored if fewer than
{MEANINGFUL_RESTRICTION_FRAC} of {set:GUARDS} have an IPv6 ORPort),
That way, we make sure every guard is usable. But we also make sure that
Tor still works on IPv4-only networks.
I considered modifying [Section:CONFIRMED] or [Section:PRIMARY] instead,
but it got very complicated, very quickly. But perhaps we should consider
using it as one of the ordering criteria as well, particularly if the
current proportion of IPv6 guards is close to
{MEANINGFUL_RESTRICTION_FRAC}.
No stable Tor release ever used `ClientPreferIPv6DirPort` for anything. It
was introduced in 0.2.8.1-alpha, and effectively ignored in 0.2.8.4-rc
when we switched to begindir for clients. We'll get rid of it in #19704.
'''Be careful about defining "public information"'''
When the proposal says: "(We do not randomize this, since it is public
information.)", it's subtly wrong. While the information about which
consensus a guard first went missing in is public, the information that
this tor client was running and downloaded a consensus on that date is
not.
In particular, if the guard went missing at the last hour on that date, it
could be used to determine whether a user's Tor Browser was open in that
particular hour. Combine several sets of information like this, and an
adversary could generate a time profile.
'''No Reachable Guards'''
{{{
[XX Problem point: we have the potential, given a sufficiently
restrictive filter, to have very few sampled guards in our
filtered set.]
}}}
I suggest we warn the user, create a different state instance "D.
Pathologically Restricted". We then make sure we initialise that state
with enough usable guards. One way of doing this is to repeatedly re-
sample, clearing it if necessary. This is ok on initialisation, because
no-one knows our previous choices.
We could make it non-persistent to avoid leaking information about our
previous restrictions, at the cost of potentially choosing an evil guard.
Or we could make the opposite choice, and leak info, but avoid evil
guards.
If we have multiple pathological environments, or all our previous guards
go down in a pathological environment, then we could throw away our
previous choices and start again. This exposes us to the risk of an evil
guard, but avoids information leaks.
It's a tradeoff. I'm not sure which way to go. But we should at least
allow users who only care about circumvention to use Tor in restrictive
environments. If we don't do this, they will complain. Loudly.
'''Minor Issues'''
{{{
- Its bridge status matches the value of UseBridges.
}}}
What is a "bridge status"?
I suggest: The bridge status of a guard is 1 if it is defined using a
Bridge line, and 0 otherwise.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19468#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list