Detect and warn when running IPv6-using client without IPv6 address privacy
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.
Activity
changed milestone to %Tor: unspecified
cmouse posted a patch to check for MAC-leaking interfaces on Linux on startup. It needs some (cosmetic and non-cosmetic) changes to fit into Tor's style (cmouse is working on those), and some further design:
- The function should report what it learns in a return value, not just in log messages, but it's not clear what needs to be returned. I suggested a simple tri-state ((a) no MAC-leaking interfaces found, (b) MAC-leaking IPv6 interface found, (c) don't know); Sebastian pointed out that that's not enough information to help the user fix a per-interface problem (but I'm not sure that's relevant on Linux).
- This function should be called more often than just once at startup. Is calling it whenever Tor detects that the computer's IP address changes often enough? Does Tor detect changes to a computer's set of IPv6 interface addresses?
- Someone will want to silence the warnings.
- Someone will have a horrible connection and change IP addresses often, and should not be spammed with warn-level messages if they don't have time to (or don't want to) fix their MAC leak.
- Someone will use a MAC changer, and not want to be warned that their computer is leaking its current (one-session-only) MAC.
Trac:
Status: new to needs_revisionI have now posted new patch which addresses the following issue:
- It now returns -1 on error, 0 on success or if it's not applicable test on this platform, or number of interfaces affected
- It accepts integer parameter, which if set to non-zero, will turn on logging
- Calling it more than once, or silencing the warning, has not been done.
Looks like this handles the Linux version okay.
I've squashed these and made the code style a little more like ours in branch "bug4806_linux" in my public repository.
Before merging, we need to think about:
- whether to be more restrictive about what interfaces we check on. If all my VM interfaces have use_tempaddr disabled, that might not be a problem. If I haven't enabled IPv6 at all, it isn't a problem.
- Backing off from read_file_to_string, or adding a new flag to that function to yield the whole file. Right now, on my linux machine at least, doing fstat() on those files in proc says that the size is 0, so the function only reads an empty string.
Perhaps the message should be just changed to more generic, like "see manual" or something?
The code only checks whether use_tempaddr is set to non-zero. It does not harm to set it to non-zero on interface which only has link-local address. It'll raise awareness on the issue.
Link-locals can be used to bypass security on same subnet if the owner is not careful...
Trac:
Username: cmouse-
Tweaked a bit as "bug4806_linux_rebased" in my public git repository.
I've tried playing with this a little, but so far the false positive rate is ridiculously high. It warns even though all my IPv6 addresses are link-local; it warns even though I'm not connecting to any IPv6 hosts. That may be a support problem. Comments?
OS X 10.7 (2011) and later have sysctl net.inet6.ip6.use_tempaddr set to 1 by default. (If a user has changed these, they know what they're doing. If an admin has, perhaps we still want to warn the user.)
Source: https://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-knowledge-base-ip-transport/enabling-ipv6-in-mac-os-x (US DoD root certificate)
Trac:
Sponsor: N/A to N/A
Severity: N/A to NormalTrac:
Parent: N/A to #17811 (moved)Replying to cypherpunks:
hello i have trouble set my tor to use IPv6 address privacy address. i can not bind to interface just by ip OutboundBindIP but the temporary address changes by random... hi, i like to use IPv6 "temporary address with privacy extension". Which i get through dhcp on eth0. Well tor applications can only bind by IP not by interface. i cannot find howto bind programm to this temporary addresses without changing default routes. Is there some type of network interface or "pseudo" adresses to use as aliases? like, bind process to FC::2 and route this through => scope global temporary dynamic
howto bind set torrc
OutboundBindIPto interface for dynamic ips like => scope global temporary dynamic IPv6 ?
We might end up using parts of this patch to avoid IPv6 address privacy on relays.
Trac:
Parent: #17811 (moved) to #5940 (moved)Replying to cypherpunks:
Replying to cypherpunks:
hello i have trouble set my tor to use IPv6 address privacy address. i can not bind to interface just by ip OutboundBindIP but the temporary address changes by random... hi, i like to use IPv6 "temporary address with privacy extension". Which i get through dhcp on eth0. Well tor applications can only bind by IP not by interface. i cannot find howto bind programm to this temporary addresses without changing default routes. Is there some type of network interface or "pseudo" adresses to use as aliases? like, bind process to FC::2 and route this through => scope global temporary dynamic
howto bind set torrc {{{ OutboundBindIP }}} to interface for dynamic ips like => scope global temporary dynamic IPv6 ?
tor doesn't support OutboundBindAddress to interfaces.
But you should be able to configure the default route at an OS level, and tor will use that for outbound connections.
Replying to cypherpunks:
Replying to teor:
We might end up using parts of this patch to avoid IPv6 address privacy on relays. but might it would benefit for exit relays exitting traffic? could result in less punishment, less captchas for tor users.
It might, but any sensible IPv6 address blocking service should be blocking at /56 or /64 (the host or local network block size), not /128 (the individual device address). So it's unlikely to work for very long.
Exit operators will get a rotating IPv6 address by default, if tor exits using the default route, and the default route uses IPv6 address privacy. (There's nothing we need to do in tor to enable this use case.)
expect the IPv6 orport
You're right, IPv6 address privacy is unhelpful for ORPorts, because they need to stay the same for at least 5 hours after they are published in the relay's descriptor. (After the descriptor is posted, it takes up to 1 hour for the authority reachability check, up to 1 hour for the consensus to be made, and up to 3 hours for all clients to get the consensus.)
mentioned in issue #5146 (moved)
mentioned in issue #5940 (moved)
moved to tpo/core/tor#4806 (closed)
mentioned in issue tpo/core/tor#5940 (closed)