Opened 9 years ago

Last modified 9 months ago

#4806 needs_revision enhancement

Detect and warn when running IPv6-using client without IPv6 address privacy

Reported by: nickm Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ipv6, tor-client, nickm-patch, intro, privacy
Cc: ln5 Actual Points:
Parent ID: #5940 Points: medium
Reviewer: Sponsor:

Description

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.

Child Tickets

Attachments (4)

20120823_check_ipv6_tempaddr.patch (3.0 KB) - added by cypherpunks 8 years ago.
Enables IPv6 tempaddr checking
0001-Adds-support-for-checking-ipv6-tempaddr-usage.patch (4.7 KB) - added by cypherpunks 8 years ago.
0002-Removed-dirent.h-from-main.c.patch (564 bytes) - added by cypherpunks 8 years ago.
0003-Fixed-to-use-tor-framework-functions.patch (3.0 KB) - added by cypherpunks 8 years ago.

Download all attachments as: .zip

Change History (46)

comment:1 Changed 9 years ago by ln5

Cc: ln5 added
Keywords: ipv6 added

comment:2 Changed 8 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.4.x-final
Priority: normalmajor

Changed 8 years ago by cypherpunks

Enables IPv6 tempaddr checking

comment:3 Changed 8 years ago by rransom

Status: newneeds_revision

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.

comment:4 Changed 8 years ago by cypherpunks

I 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.

Changed 8 years ago by cypherpunks

Changed 8 years ago by cypherpunks

comment:5 Changed 8 years ago by cypherpunks

Status: needs_revisionneeds_review

comment:6 Changed 8 years ago by cypherpunks

Status: needs_reviewneeds_revision

Should be okish now

comment:7 Changed 8 years ago by cypherpunks

Status: needs_revisionneeds_review

comment:8 Changed 8 years ago by nickm

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.

comment:9 Changed 8 years ago by nickm

Another thing to think about: Maybe this shouldn't warn about link-local addresses.

comment:10 Changed 8 years ago by nickm

Other ideas (not mine): perhaps we should recommend editing /etc/sysctl.conf rather than calling sysctl(8)

comment:11 Changed 8 years ago by cmouse

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...

comment:12 Changed 8 years ago by nickm

Keywords: tor-client added

comment:13 Changed 8 years ago by nickm

Component: Tor ClientTor

comment:14 Changed 8 years ago by nickm

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?

comment:15 Changed 8 years ago by nickm

I did a little work last night on an alternate approach that could be better for 0.2.5. (It's missed the 0.2.4 release deadline). It's in branch "bug4806_gently_v2" in my public repository.

comment:16 Changed 8 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

After discussion with andrea, moving to 0.2.5. Doing this only on linux with a high false positive rate is not really better than not doing it at all .. and the revised patch is too late for the 0.2.4 merge window.

comment:17 Changed 7 years ago by nickm

Status: needs_reviewneeds_revision

comment:18 Changed 7 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final
Status: needs_revisionneeds_review

This isn't tested enough for 0.2.5 IMO, and the code seems likely to need rebasing given other changes to get_interface_address6().

comment:19 Changed 6 years ago by nickm

Keywords: 026-triaged added
Status: needs_reviewneeds_revision

comment:20 Changed 6 years ago by nickm

Keywords: 026-triaged-0 added; 026-triaged removed

comment:21 Changed 6 years ago by nickm

Keywords: nickm-patch added

comment:22 Changed 6 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final

comment:23 Changed 6 years ago by nickm

Keywords: 027-triaged-1-out added

Marking triaged-out items from first round of 0.2.7 triage.

comment:24 Changed 6 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

Move *most* 0.2.7-triaged-1-out needs_revision items into 0.2.???. Keep a few based on my sense of the sensible.

comment:25 Changed 5 years ago by teor

Severity: Normal

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)

comment:26 Changed 5 years ago by teor

Parent ID: #17811

comment:27 Changed 5 years ago by nickm

Keywords: intro added

comment:28 Changed 5 years ago by nickm

Points: medium

comment:29 Changed 4 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:30 Changed 4 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:31 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:32 Changed 3 years ago by nickm

Keywords: 027-triaged-in added

comment:33 Changed 3 years ago by nickm

Keywords: 027-triaged-in removed

comment:34 Changed 3 years ago by nickm

Keywords: 027-triaged-1-out removed

comment:35 Changed 3 years ago by nickm

Keywords: 026-triaged-0 removed

comment:36 Changed 3 years ago by nickm

Keywords: privacy added

comment:37 Changed 16 months ago by 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...

comment:38 in reply to:  37 ; Changed 10 months ago by 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 ?

comment:39 Changed 9 months ago by teor

Parent ID: #17811#5940

We might end up using parts of this patch to *avoid* IPv6 address privacy on relays.

comment:40 in reply to:  38 Changed 9 months ago by teor

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.

comment:41 in reply to:  39 ; Changed 9 months ago by 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.

expect the IPv6 orport

comment:42 in reply to:  41 Changed 9 months ago by teor

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.)

Note: See TracTickets for help on using tickets.