Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
T
Tor
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,069
    • Issues 1,069
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 20
    • Merge Requests 20
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • The Tor Project
  • Core
  • Tor
  • Issues
  • #4806

Closed
Open
Opened Dec 30, 2011 by Nick Mathewson@nickm🐭Owner

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.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: tpo/core/tor#4806