Privacy: mangle output packet TTL/HL values to reduce discrimination by service providers

S0AndS0 commented 10 months ago

Problem

Certain service providers use Time To Live (TTL), and Hop Limit (HL), values to differentiate between packets originating from a host device vs client devices connected via tethering.

Currently client devices must set their TTL/HL values to 65, one greater than that of the host (at the time of writing 64), so that after exiting through tethering route the value matches packets generated by the host. However, this workaround only works for Linux clients reliably, MicroSoft Windows clients maybe, and MacOS almost not at all... and smart devices almost certainly not.

Proposed Solution

Mangle all outbound packets to have the same TTL, and HL, value(s) as the host host device;

# Bash script example for host when initializing tethering
_interface_name_output='rmnet'

_packet_time_to_live="$(cat /proc/sys/net/ipv4/ip_default_ttl)"

_packet_hop_limit="$(cat /proc/sys/net/ipv6/conf/default/hop_limit)"

iptables -t mangle -i POSTROUTING -o "${_interface_name_output}" -j TTL --ttl-set "${_packet_time_to_live}"

ip6tables -t mangle -i POSTROUTING -o "${_interface_name_output}" -j HL --hl-set "${_packet_hop_limit}"

Downsides:

all packets, including those produced by host device, are mangled
only targets one output interface, and would be better as a set of PREROUTING rules for input interfaces
no easy route, I could find, to enable/disable packet mangling via Android Settings UI
if always on could be less performant, and/or drain battery faster, due to doing extra work for every outbound packet

Upsides:

improves privacy by reducing opportunity for service providers to discriminate against tethered network clients
allows any tethered network client to use host device's internet connection without modifying client(s) networking configurations
could be made apart of init/boot processes
should not adversely effect host networking if left on all the time, other than previously mentioned performance/battery considerations

Alternatives

Define above iptables rules on device between host and clients such as what the following ASCII diagram attempts to show...

         +--------+
         | Phone  |
         +--------+
             ↕
         +--------+
         |  RPi   |
         +--------+
          ↕      ↕
+----------+    +----------+
| Client 1 |    | Client 2 |
+----------+    +----------+

... Though this should work, it kinda feels clunky and also prevents easy communication between phone/host and clients.

# RPi tethering repeater Bash script example
_iface='wlan0'
_ttl=65

iptables -t mangle -i POSTROUTING -o "$(_iface)" -j TTL --ttl-set "$(_ttl)"

ip6tables -t mangle -i POSTROUTING -o "$(_iface)" -j HL --hl-set "$(_ttl)"

Possible Points of Interest

I have searched a bit about within the available source code, in hopes that an avenue to implement changes would be found without too much struggle, and here are some of the directories/files that seemed relevant;

Musings

GrapheneOS/platform_packages_apps_Settings -- src/com/android/settings/network/tether/TetheringManagerModel.java defines useful interface that may be hooked into for start/stop tethering events. Though if I remember correctly the SELinux configuration(s) may also need updated to allow this code to touch iptables related binaries.
GrapheneOS/platform_packages_apps_Settings -- src/com/android/settings/network/tether/TetherSettings.java may need alterations to allow device owners to toggle TTL mangling on/off.
Though it'd be nice to have a full front-end for iptables, without needing to root, that ain't what I be after because that seems like way too much... for now ;-D

Questions

were I to pursue implementing the proposed solution, are there any concerns/suggestions core maintainers have?
I saw mention that eBPF may be preferred for future development, anyone got pointers on properly mangling TTL/HL values via that API instead of iptables?

Possibly Related Issues

thestinger commented 10 months ago

What about the hardware offload?

S0AndS0 commented 10 months ago

If it is an xOR sort of thing and hardware offload is already enabled, then I think toggling on TTL mangling should turn-off hardware offload and send a toast/notification to device owner, and vice versa for toggling on hardware offload on when TTL mangling is enabled.

Also I think any new mangling features should probably be opt-in, regardless of if it plays nice with hardware offload features.

thestinger commented 10 months ago

I don't know if the hardware offload supports it but I doubt it. It would need to disable it.

thestinger commented 9 months ago

Getting information from ChatGPT is not helpful and we don't allow posting AI generated answers on the discussion forum or issue tracker.

thestinger commented 8 months ago

Duplicate of https://github.com/GrapheneOS/os-issue-tracker/issues/993.

GrapheneOS / os-issue-tracker