[tor-commits] [torspec/master] Prop 312: Require explicit authority addresses
teor at torproject.org
teor at torproject.org
Wed Feb 5 12:07:24 UTC 2020
commit 89e7222f65a06bead82e9ae63d5b87a518c5d38c
Author: teor <teor at torproject.org>
Date: Tue Feb 4 14:50:04 2020 +1000
Prop 312: Require explicit authority addresses
Only use explicit IPv4 and IPv6 address literals, configured in Address
or ORPort lines, for directory authority addresses.
As suggested by Nick Mathewson.
Part of 33073.
---
proposals/312-relay-auto-ipv6-addr.txt | 104 ++++++++++++++++++++++++++++-----
1 file changed, 89 insertions(+), 15 deletions(-)
diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt
index 2fdb79a..e434267 100644
--- a/proposals/312-relay-auto-ipv6-addr.txt
+++ b/proposals/312-relay-auto-ipv6-addr.txt
@@ -50,12 +50,16 @@ Ticket: #33073
* start using IPv4 ORPort for IPv4 address detection, and
* re-order IPv4 address detection methods.
- Relays and directory authorities (but not bridges):
+ Relays (but not bridges, or directory authorities):
* fetch some directory documents over IPv6.
+
For anonymity reasons, bridges are unable to fetch directory documents over
IPv6, until clients start to do so. (See
[Proposal 306: Client Auto IPv6 Connections].)
+ For security reasons, directory authorities must only use addresses that
+ are explicitly configured in their torrc.
+
This proposal makes a small, optional change to existing client behaviour:
* clients also check IPv6 addresses when rotating TLS keys for new
networks.
@@ -90,7 +94,9 @@ Ticket: #33073
To discover their IPv6 address, some relays may fetch directory documents
over IPv6. (For anonymity reasons, bridges are unable to fetch directory
- documents over IPv6, until clients start to do so.)
+ documents over IPv6, until clients start to do so. For security reasons,
+ directory authorities only use addresses that are explicitly configured in
+ their torrc.)
3.1. Current Relay IPv4 Address Implementation
@@ -137,10 +143,13 @@ Ticket: #33073
the traffic without the relay's private keys, but they can monitor traffic
patterns.
- Therefore, we only use untrusted address discovery methods, if every other
- method has failed. Any method that uses DNS is potentially untrusted,
- because DNS is often a remote, unauthenticated service. And addresses
- provided by other directory servers are also untrusted.
+ Therefore, relays should only use untrusted address discovery methods, if
+ every other method has failed. Any method that uses DNS is potentially
+ untrusted, because DNS is often a remote, unauthenticated service. And
+ addresses provided by other directory servers are also untrusted.
+
+ For security reasons, directory authorities only use addresses that are
+ explicitly configured in their torrc.
Based on these principles, we propose that tor tries to find relay IPv4 and
IPv6 addresses in this order:
@@ -224,6 +233,12 @@ Ticket: #33073
tor is configured with a custom set of directory authorities, private
addresses should be allowed, with a notice-level log.)
+ For security reasons, directory authorities only use addresses that are
+ explicitly configured in their torrc. Therefore, we propose that directory
+ authorities only accept IPv4 or IPv6 address literals in their Address
+ option. They must not attempt to resolve their Address using DNS. It is a
+ config error to provide a hostname as a directory authority's Address.
+
If the Address option is not configured for IPv4 or IPv6, or the hostname
lookups do not provide both IPv4 and IPv6 addresses, address resolution
should go to the next step.
@@ -250,6 +265,19 @@ Ticket: #33073
In rare cases, relays may have been using non-advertised ORPorts for their
addresses. This change may also change their addresses.
+ For security reasons, directory authorities only use addresses that are
+ explicitly configured in their torrc. Therefore, we propose that directory
+ authorities only accept IPv4 or IPv6 address literals in the address part
+ of the ORPort and DirPort options. They must not attempt to resolve these
+ addresses using DNS. It is a config error to provide a hostname as a
+ directory authority's ORPort or DirPort.
+
+ If directory authorities don't have an IPv4 address literal in their
+ Address or ORPort, they should issue a configuration error, and refuse to
+ launch. If directory authorities don't have an IPv6 address literal in their
+ Address or ORPort, they should issue a notice-level log, and fall back to
+ only using IPv4.
+
For the purposes of address resolution, tor should ignore private
configured ORPort addresses on public tor networks. (Binding to private
ORPort addresses is supported, even on public tor networks, for relays that
@@ -285,6 +313,12 @@ Ticket: #33073
socket. (UDP is used because it is stateless, so the OS will not send any
packets to open a connection.)
+ For security reasons, directory authorities only use addresses that are
+ explicitly configured in their torrc. Since local interface addresses are
+ implicit, and may depend on DHCP, directory authorities do not use this
+ address resolution method (or any of the other, lower-priority address
+ resolution methods).
+
Relays that use NAT to reach the Internet may have no publicly routable
local interface addresses, even on the public tor network. The NAT box has
the publicly routable addresses, and it may be a separate machine.
@@ -310,10 +344,9 @@ Ticket: #33073
* the local hostname.
However, OS APIs typically only return a single hostname.
- Even though the hostname lookup may use remote DNS, we propose to use it on
- directory authorities, to maintain compatibility with current
- configurations. Even if it is remote, we expect the configured DNS to be
- somewhat trusted by the operator.
+ For security reasons, directory authorities only use addresses that are
+ explicitly configured in their torrc. Since hostname lookups may use DNS,
+ directory authorities do not use this address resolution method.
The hostname lookup should ignore private addresses on public relays. If
multiple IPv4 or IPv6 addresses are returned, the first public address from
@@ -334,11 +367,10 @@ Ticket: #33073
directory fetches, bridge behaviour can also change to match. (See
section 3.4.1 and [Proposal 306: Client Auto IPv6 Connections].)
- We propose that directory authorities should ignore addresses in directory
- headers. Allowing other authorities (or relays) to change a directory
- authority's published IP address may lead to security issues. Instead,
- if interface and hostname lookups fail, tor should stop address resolution,
- and return a permanent error. (And issue a log to the operator, see below.)
+ For security reasons, directory authorities only use addresses that are
+ explicitly configured in their torrc. Since directory headers are provided
+ by other directory servers, directory authorities do not use this address
+ resolution method.
We propose to use a simple load balancing scheme for IPv4 and IPv6
directory requests:
@@ -606,6 +638,11 @@ Ticket: #33073
See section 3.5 for some factors to consider when making this design
decision.
+ For security reasons, directory authorities only use addresses that are
+ explicitly configured in their torrc. Since directory headers are provided
+ by other directory servers, directory authorities do not use this address
+ resolution method.
+
For anonymity reasons, bridges are unable to fetch directory documents over
IPv6, until clients start to do so. (See
[Proposal 306: Client Auto IPv6 Connections].)
@@ -680,6 +717,11 @@ Ticket: #33073
relays will be forced to make new connections when their address changes,
then tor may be able to stop using X-Your-Address-Is HTTP headers.
+ For security reasons, directory authorities only use addresses that are
+ explicitly configured in their torrc. Since NETINFO cells are provided
+ by other directory servers, directory authorities do not use this address
+ resolution method.
+
Bridges only make OR connections, and those OR connections are only over
IPv4, to imitate default client behaviour.
@@ -702,6 +744,9 @@ Ticket: #33073
Relays prefer IPv4 and IPv6 address suggestions received from Directory
Authorities.
+ Directory authorities do not use these address detection methods to
+ discover their own addresses, for security reasons.
+
When they receive an address suggestion from a directory mirror, relays can:
* ignore the address, or
* use the address as the lowest priority address method.
@@ -723,6 +768,9 @@ Ticket: #33073
We propose some optional changes to improve relay (and bridge)
load-balancing across directory authorities.
+ Directory authorities do not use these address detection methods to
+ discover their own addresses, for security reasons.
+
3.5.3.1. Directory Authority Load Balancing
Relays may prefer:
@@ -733,6 +781,9 @@ Ticket: #33073
Both these changes are optional, so they might not be implemented.
+ Directory authorities do not use these address detection methods to
+ discover their own addresses, for security reasons.
+
If both changes are implemented, we would like all relays (and bridges) to
do frequent directory fetches:
* using BEGINDIR over ORPorts,
@@ -813,6 +864,9 @@ Ticket: #33073
IPv6, until clients start to do so. (See
[Proposal 306: Client Auto IPv6 Connections].)
+ Directory authorities do not use these address detection methods to
+ discover their own addresses, for security reasons.
+
This change may only be necessary if the following changes result in poor
load-balancing, or other relay issues:
* randomly selecting IPv4 or IPv6 directories (see section 3.2.5), or
@@ -871,6 +925,9 @@ Ticket: #33073
IPv6, until clients start to do so. (See
[Proposal 306: Client Auto IPv6 Connections].)
+ Directory authorities do not use these address detection methods to
+ discover their own addresses, for security reasons.
+
In this proposal, relays choose between IPv4 and IPv6 directory fetches
at random (see section 3.2.5 for more detail). But if this change causes
issues on IPv4-only relays, we may have to try IPv6 less often.
@@ -937,6 +994,9 @@ Ticket: #33073
IPv4 and IPv6 address detection (see section 3.2.3), on relays
(and bridges).
+ Directory authorities do not use this address detection method to
+ discover their own addresses, for security reasons.
+
Rewrite the get_interface_address*() functions to choose an interface
address on the default route, or to sort default route addresses first in
the list of addresses. (If the platform API allows us to find the default
@@ -958,6 +1018,9 @@ Ticket: #33073
* automatic hostname resolution (see section 3.2.4),
on relays and bridges.
+ Directory authorities do not use this address detection method to
+ discover their own addresses, for security reasons.
+
Use gethostbyname2() to add IPv6 support to hostname resolution on older
OSes, which don't support getaddrinfo().
@@ -1021,6 +1084,12 @@ Ticket: #33073
bridges) that use IPv6 address privacy extensions (see section 3.5 of
[RFC 4941: Privacy Extensions for IPv6]).
+ Directory authorities:
+ * should not use IPv6 address privacy extensions, because their addresses
+ need to stay the same over time, and
+ * do not use address detection methods that would automatically select
+ an IPv6 address with privacy extensions, for security reasons.
+
We propose that tor should avoid using IPv6 addresses generated using
privacy extensions, unless no other publicly routable addresses are
available.
@@ -1124,6 +1193,11 @@ Ticket: #33073
firewall notifications which show a strange IP address, particularly on
clients.)
+ Directory authorities do not use a UDP socket to discover their own
+ addresses, for security reasons. Therefore, we are free to use any
+ directory address for this check, without the risk of a directory authority
+ making a UDP socket to itself, and discovering its own private address.
+
We propose that tor should use a directory authority IPv4 and IPv6 address,
for any sockets that it opens to detect local interface addresses (see
section 3.2.3). We propose that this change is applied regardless of the
More information about the tor-commits
mailing list