Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:49:56Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32954Stop public authorities specifying an internal address for their IPv6 ORPort2020-06-13T15:49:56ZteorStop public authorities specifying an internal address for their IPv6 ORPortWhen we implement `Address [IPv6]` in #30954, we should check that the supplied IPv6 address is a public address on Directory Authorities.
This matches the current `Address IPv4` check for authorities.When we implement `Address [IPv6]` in #30954, we should check that the supplied IPv6 address is a public address on Directory Authorities.
This matches the current `Address IPv4` check for authorities.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32888Log address config info when tor starts up2020-06-13T15:49:47ZteorLog address config info when tor starts upWe're going to be modifying tor's address detection and reachability code for an upcoming sponsor. To help us debug, we should log the following info when tor starts up:
IPv4:
* the `Address` torrc option
* and whether it is an IP add...We're going to be modifying tor's address detection and reachability code for an upcoming sponsor. To help us debug, we should log the following info when tor starts up:
IPv4:
* the `Address` torrc option
* and whether it is an IP address, or a DNS name
* the local hostname
* and whether it is an IP address, or a DNS name
* the local network interface addresses
See `resolve_my_address()` for details.
IPv6:
* the IPv6 address of the first IPv6 `ORPort` torrc option
See `router_build_fresh_descriptor()` and `router_get_advertised_ipv6_or_ap()` (in #32588) for details.
When (or if) we use them as part of address detection, we should also log the following info:
IPv4 and IPv6:
* the `Address` torrc option
* and whether it is an IP address, or a DNS name
* the IPv4 and IPv6 addresses of the first `ORPort` torrc option of each address family
* the local hostname
* and whether it is an IP address, or a DNS name
* the local network interface addresses
Notes:
* We'll need a proposal to decide if `ORPort` or hostname should come first
* We'll probably want a summary at notice level, and then detailed logs at info level
* If all these methods fail, relays use `X-Your-Address-Is:` headers from directory authorities. They are out of scope, because they are not available at startup.
* Similarly, we won't print address reachability self-testing info, because it's not available at startup.
* We may want to print similar log messages (including `X-Your-Address-Is:` and reachability info) as part of tor's regular heartbeat messages. But that deserves a separate ticket.
I don't think we'll use (or log):
* the addresses of any `DirPort` torrc options
* the addresses of multiple `ORPort` torrc optionsTor: unspecifiedcchttps://gitlab.torproject.org/legacy/trac/-/issues/32707need a mechanism to automatically detect the ipv6 address of the node2020-06-13T15:49:00ZTracneed a mechanism to automatically detect the ipv6 address of the nodebecause for a dynamic ipv6 address specifying the current ipv6 address requires automatic editing torrc by a scripts(or have i found no other way). it is also necessary to automatically detect when the ipv6 address changes as it is done ...because for a dynamic ipv6 address specifying the current ipv6 address requires automatic editing torrc by a scripts(or have i found no other way). it is also necessary to automatically detect when the ipv6 address changes as it is done for ipv4
**Trac**:
**Username**: babutTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24777Make relays try IPv6 ORPorts for directory uploads and downloads2020-06-13T15:19:44ZteorMake relays try IPv6 ORPorts for directory uploads and downloadsUsing IPv6 ORPorts will make relay behaviour consistent with future client behaviour.
The only difference is that relays will also use IPv4 DirPorts, but clients will not.
Relays should try to upload descriptors using IPv4 and IPv6 as ...Using IPv6 ORPorts will make relay behaviour consistent with future client behaviour.
The only difference is that relays will also use IPv4 DirPorts, but clients will not.
Relays should try to upload descriptors using IPv4 and IPv6 as well, to detect authority connectivity issues.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19919If ORPort address is publicly routable, use it to guess Address2020-06-13T15:04:48ZteorIf ORPort address is publicly routable, use it to guess AddressSplitting this off from #13953: we'll warn in that ticket, and make the change to the address resolution order in this one.Splitting this off from #13953: we'll warn in that ticket, and make the change to the address resolution order in this one.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17605Stop HTTP caches storing or modifying X-Your-Address-Is from Tor Directory do...2020-06-13T14:51:03ZteorStop HTTP caches storing or modifying X-Your-Address-Is from Tor Directory documentsSome web caches (such as Farahavar's previous cache), pass on the X-Your-IP-Address-Is header from one directory document to multiple clients. This causes the clients to guess the wrong IP address as their address.
I think we should add...Some web caches (such as Farahavar's previous cache), pass on the X-Your-IP-Address-Is header from one directory document to multiple clients. This causes the clients to guess the wrong IP address as their address.
I think we should add one or more of the following headers to every directory response:
`Pragma: no-cache` tells HTTP 1.0 compliant caches to disable caching entirely. (This will also disable caching for HTTP 1.1 caches unless we provide a more generous Cache-Control header, like the one below.)
`Connection: close X-Your-IP-Address-Is` tells HTTP 1.1 caches to never send out the X-Your-IP-Address-Is header, even to the first client requesting the document.
`Cache-Control: no-cache="X-Your-IP-Address-Is"` tells HTTP 1.1 caches to not cache the header at all. Alternately, if the cache doesn't support the no-cache="<header-name>" feature, it tells the cache not to cache the entire document. (This also causes the cache to attempt to revalidate the header, which might not be what we want, as Tor doesn't support cache revalidation.)
I don't know enough about how caches typically behave to recommend which ones.
See:
* #16205 - bogus IP address / clock change from authority server
* https://lists.torproject.org/pipermail/tor-relays/2015-November/008137.htmlTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/12377Prefer default route when checking local interface addresses2020-06-13T14:36:49Zrl1987Prefer default route when checking local interface addressesFirst, let us assume that all network interfaces for IP host that runs Tor instance are internal as judged by `tor_addr_is_internal()` function.
There is the following code in `get_interface_address6()` function.
```
/* Try to do thi...First, let us assume that all network interfaces for IP host that runs Tor instance are internal as judged by `tor_addr_is_internal()` function.
There is the following code in `get_interface_address6()` function.
```
/* Try to do this the smart way if possible. */
if ((addrs = get_interface_addresses_raw(severity))) {
int rv = -1;
SMARTLIST_FOREACH_BEGIN(addrs, tor_addr_t *, a) {
if (family != AF_UNSPEC && family != tor_addr_family(a))
continue;
if (tor_addr_is_loopback(a) ||
tor_addr_is_multicast(a))
continue;
tor_addr_copy(addr, a);
rv = 0;
/* If we found a non-internal address, declare success. Otherwise,
* keep looking. */
if (!tor_addr_is_internal(a, 0))
break;
} SMARTLIST_FOREACH_END(a);
SMARTLIST_FOREACH(addrs, tor_addr_t *, a, tor_free(a));
smartlist_free(addrs);
return rv;
}
```
Caller will get the last entry from a interface address smartlist. Is this okay?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4806Detect and warn when running IPv6-using client without IPv6 address privacy2020-06-13T14:19:47ZNick MathewsonDetect and warn when running IPv6-using client without IPv6 address privacyLots of IPv6 implementations default to deriving the last 48 bits of the address from local host's ethernet MAC address. There's an optional, usually-off-by-default feature that randomizes addresses for outbound connections (see RFC 494...Lots of IPv6 implementations default to deriving the last 48 bits of the address from local host's ethernet MAC address. There's an optional, usually-off-by-default feature that randomizes addresses for outbound connections (see RFC 4941), but not all clients will know where it is, or know how to turn it on.
That's problematic for users on laptops or other mobile devices, since their MAC address provides a way to tell it's still them as they move around the network.
Perhaps when Tor is running as a client, we should detect whether the address(es) we're using on outbound connections match any MAC address, and warn if so. (Without root, we can't do more than warn and suggest a workaround.)
On Windows, it's part of the info we get from GetAdaptersAddresses(). On Linux and OSX this info *seems* to be available via getifaddrs(): we just need to check for AF_PACKET addresses on Linux and AF_LINK addresses on Mac. BSDs seem to do the same thing as OSX here.
Failing that, on Linux, we can learn the MAC address of a socket with ioctl(SIOCGIFHWADDR). On OSX, it looks like we might need to mess around with the IOKit framework and a chain of twisty little calls that start with IOServiceMatching and end no place good.
We'll need to suggest some action for the user to take. For a relay, no action is necessary. For a bridge, I'm not too sure. For a client, the OSX and FreeBSD fix appears to be "sysctl -w net.inet6.ip6.use_tempaddr=1 " ; On Linux, it's maybe "sysctl net.ip6.conf.if.use_tempaddr=2". On Windows, it's probably somthing fiddly.Tor: unspecified