View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003896||GNUnet||transport service||public||2015-07-17 01:19||2022-03-15 15:49|
|Product Version||Git master|
|Summary||0003896: GNUnet HELLOs break privacy, especially on IPv6|
|Description||GNUnet's transports publish all IPv6 addresses they listen on.|
However, only globally routed addresses should be made available publicly. Also it is questionable whether EUI-64 addresses should be published at all, as users usually do not randomize their MAC addresses and thus leak their client device's indentity with every single network packet when using EUI-64 generated IPv6 addresses when using addresses using that scheme defined in RFC 2373 Appendix A.
This is even more of a problem if RFC 3041 privacy addresses are configured on the same interface and prefix, in that case only the Temporary Addresses as defined in RFC 3041 should be bound and used for GNUnet by default.
Similarly, leaking addresses allocated wthin (constant!) local ULAs as in RFC 4193 which should not be made available globally.
On IPv4, the same issue also exists as addresses within the private ranges defined by RFC 1918 (192.168/16, 10/8, 172.16/12)
The same applies to any non-globally addresses identifying local WiFi or bluetooth interfaces.
Generally, when using GNUnet inside private or local networks *as well as* public global internets, GNUnet should make sure not to leak the users identity on one network onto any other network.
Thus, peerinfo should be provided in a source-routing manner depending on who is asking and only provide addresses within the same family (v4,v6,802.1) and isolate public/private ranges.
Providing peering information over a certain interface which are outside of the routable range of that interface rarely provides any benefit compared to the huge privacy issue it creates.
|Steps To Reproduce||Install GNUnet. Oops, I just leaked my hardware MAC addresses...|
Ok, this is going to be a complicated discussion, but maybe worth it.
First of all, you're confusing 'user identity' and 'peer identity'.
HELLOs allow other peers to link your network addresses to your peer identity.
That's by design, and anonymous routing should be used to decouple the actions of your user(s) from your peer (so that it is no longer clear which actions/users are originating from which peer). If you want to globally hide your IP address, you need to configure GNUnet in F2F-mode and hope that your friends don't disclose the information (the code contains a flag to let them know that they shouldn't do this). But that's not quite the question here, I'm just explaining to make sure we're on the same page.
Now, I read two or three issues in your report, which is basically that we should disclose less information (which, I agree, would always be good):
1) with respect to private or link-local LAN IPs, you argue that they are useless beyond the link/LAN and should thus not be globally announced;
2) with respect to IPv6-addresses containing the user's MAC, you argue those should not be disclosed "ever"
3) with respect to an IPv6 interface having multiple IPv6-IPs, you argue we should then definitively only use the 'privacy' IP.
My problem is that I agree philosophically, but disagree technically. Let me explain: you may have two peers in the same LAN. They could nicely bypass the NAT, or not even configure global IPv6 addresses using local addresses. So those addresses *are* sometimes useful to talk to other peers --- and we may never know up-front that those peers are in our LAN. And if we get their global IP only, and the NAT doesn't support hairpinning, we'll just not be able to connect to them -- on the LAN!!! What a disaster. :-).
Anyway, this is why we typically grab all IPs we can get hold of, just in hope that they might be useful (note that the WLAN transport will quite explicitly advertise your MAC just for that very purpose!).
Now, I could imagine a compromise setting, where we use the existing IPv6 multicast and UDP/WLAN broadcasts to announce LAN/LL/MAC addresses, but don't stick those into "global" announcements. That'll limit the LAN-discovery to UDP/WLAN, but maybe that's enough (especially since that LAN discovery could still also discover TCP LAN addresses via the UDP announcements).
I think this would make a good default -- but it will be tricky to implement right (but likely worthwile, as shipping all of those LAN IPs globally is pretty useless/wasteful -- in addition to the privacy issue).
With respect to global IPv6 addresses including a MAC, that IS a fundamental configuration bug of the OS and not a GNUnet issue. For that, my answer would be that you should fix your OS setup. That's not GNUnet's fault.
Also, if a system has multiple globally routable IPv6 addresses, I don't see how we could decide which ones would be better to use. I do think the user can already specify a particular IP to use exclusively via config option. But automatically, I have no hope.
My 2 cents, comments welcome!
Oh, and thanks for the interesting report.
You fully understood the issues and I agree with the solutions you suggest as well as with the fact that most problems on this planet are due to wrong configuration of all the other stuff out there ;)
You are right that this shouldn't directly compromise the privacy of GNUnet users. However, it exposes identifying bits about the system running GNUnet and it's network environment which is still a serious problem, given that this could be avoided.
I also agree that IPv4 addresses within the private ranges (RFC 1918) are sometimes useful for peers to connect when behind the same NAT but inside different isolated broadcast/multicast domains. The impact of making RFC 1918 addresses public is not that big when behind telco-supplied stock-routers, but may be more servere when inside a larger piece of non-globally-routed infrastructure such as DN42 or networks of big organizations.
Regarding the choice of IPv6 addresses to publish globally, it's easy to recognize globally routed addresses (2::/8 I guess). Classifying potentially privacy-breaking EUI-64 generated addresses is just as easy as their 12th and the 13th octect are always 0xff and 0xfe.
It is true that privacy-decissions have been pushed down from the OS level to the application level in the current IPv6 modell. Browsers and other applications responded and use only addresses chosen based on the purpose of the application (local/global, identifyable/anonymous) from a set of addresses (I'm not saying that I love the idea of browsers doing STUN in other places which has an impact similar to what's being discussed here).
Clearly, the current situation of IPv6 is not GNUnet's fault. Nevertheless GNUnet has to make wise choices to provide a maximum of safety to potentially naiive users. I kind of agree with your more-radical-than-intended re-phrasing of point 2), however, I believe that applies even more on systems with RFC 3041 privacy addresses configured where GNUnet's current behaviour also impacts other applications used on the same system as it practically undermines the whole concept of RFC 3041 which assumes that the permanent (= containing the MAC) address is never going to be associated to a temporary (= random) address...
This issue is similar to
http://www.heise.de/netze/meldung/Firefox-und-Chrome-verraten-IP-Adressen-trotz-VPN-2534438.html (article about Firefox leaking IPs of *other* interfaces if WebRTC is enabled).
Just like here, a method intended to easy NAT-traversal and allow peers to discover more feasible paths between each other can be a privacy-leak.
Fuck you Mantis, I wrote three paragraphs in here with useful information but Mantis told me my session has expired and when I went back in the browser it even deleted the input form.
Excuse me, this software is the greatest crap I've seen in a long while. Whoever wrote this code has no clue of website application design. Can we have something better real soon?
I was saying, the WebRTC scandal cannot be compared because it exposes people using Tor or VPN to any website that comes asking... whereas GNUnet only exposes the fact that you are using GNUnet.
But still the info that is being exposed could be reduced by doing more pro-active broadcasting on the LAN as discussed in https://gnunet.org/bugs/view.php?id=3802 and similarly active announcements over local radio should be sufficient to make GNUnet nodes find each other via ad-hoc wifi.
|You don't want to know how often that has hit me. But: most other systems are also crap, and then there is the question of how to migrate the info that is in Mantis right now...|
|As for the broadcasts, the issue is that AFAIK this will only work on the LAN if the ports match and if broadcasts are enabled, and then only for UDP. Neither of these assumptions will be certainly true.|
Ok, created https://gnunet.org/bugs/view.php?id=4143 to suggest a fix for the mantis problem.
Concerning broadcasts, well there was a time when it was normal that a program was going to broadcast on the LAN.. surprises me, that this has become such a big deal. When installing gnunet we have root permissions. When starting gnunet there are things that are executed as root. I think it should be the default behaviour to open up a UDP listen on a predefined port for LAN broadcasts and that at each change of LAN configuration some gnunet daemon issues a broadcast to see if there is life out there.
And I wonder what keeps us from sending local radio broadcasts in a similar way. From the description I really thought gnunet nodes would autodetect each other as soon as they are in radio vicinity.
lynX: Please understand all implications of the current behaviour. Apart from using the fact that GNUnet is being used, it does *associate* the different addresses of a box with each other (e.g. private and public IPv4, EUI-64 IPv6, temporary IPv6 -- and all that for *all* interfaces -- plus bluetooth MAC, wifi MAC which usually directly correlate with a unique piece of hardware).
Imho this is even worse than the so-called WebRTC scandal because:
* it's easy to disable WebRTC in Firefox whereas GNUnet depends on HELOs to work
* it exposes these highly identifying bits (MACs) combined with ARPA network location globally to everyone and not only to websites visited (usually this information remains local)
* even if people decide to entirely disable IPv6, this would still expose their wifi and bluetooth mac addresses *beyond the (local) scope* these details are useful.
||partially adressed by https://gnunet.org/git/gnunet.git/commit/?id=6aa3cedfa5e9df7aacbbdcf62c977e09b0e7f6c3|
FWIW, attached is the patch I'm using to hide private LAN addresses from my HELLO. I've raised this issue a few years ago on IRC, too, we didn't arrive at any action plan. Here's the patch, in case people find this and want to fix their HELLO.
hide-lan-addresses-from-hello.patch (572 bytes)
diff --git a/src/nat/gnunet-service-nat.c b/src/nat/gnunet-service-nat.c index dd0715785..06b8df5b9 100644 --- a/src/nat/gnunet-service-nat.c +++ b/src/nat/gnunet-service-nat.c @@ -736,6 +736,9 @@ check_notify_client (struct LocalAddressList *delta, (! is_nat_v4 (&c4->sin_addr)) ) continue; /* this IP is not from private address range, and IP does not match. */ + if ( is_nat_v4 (&v4.sin_addr) ) + continue; /* this IP is from private address range */ + /* OK, IP seems relevant, notify client */ if (0 == htons (v4.sin_port))
hide-lan-addresses-from-hello.patch (572 bytes)
|2015-07-17 01:19||dangole||New Issue|
|2015-07-17 22:54||Christian Grothoff||Note Added: 0009462|
|2015-07-18 22:29||dangole||Note Added: 0009465|
|2015-07-22 10:10||Christian Grothoff||Severity||major => feature|
|2015-07-22 10:10||Christian Grothoff||Status||new => acknowledged|
|2016-01-15 11:08||dangole||Note Added: 0010055|
|2016-01-15 11:11||dangole||Note Edited: 0010055|
|2016-01-23 02:01||lynX||Note Added: 0010087|
|2016-01-23 02:03||lynX||Note Added: 0010088|
|2016-01-23 02:04||lynX||Note Edited: 0010087|
|2016-01-23 11:11||Christian Grothoff||Note Added: 0010089|
|2016-01-23 11:12||Christian Grothoff||Note Added: 0010090|
|2016-01-23 14:38||lynX||Note Added: 0010091|
|2016-01-27 09:50||dangole||Note Added: 0010104|
|2016-01-27 09:50||dangole||Note Edited: 0010104|
|2016-01-27 09:51||dangole||Note Edited: 0010104|
|2016-12-02 00:23||dangole||Note Added: 0011560|
|2018-06-07 23:36||Christian Grothoff||Status||acknowledged => confirmed|
|2018-06-07 23:36||Christian Grothoff||Category||peerinfo service => transport service|
|2018-08-04 22:12||redfish||File Added: hide-lan-addresses-from-hello.patch|
|2018-08-04 22:12||redfish||Note Added: 0013173|
|2019-02-12 09:22||Christian Grothoff||Target Version||=> 0.12.0|
|2019-05-02 14:40||Christian Grothoff||Relationship added||related to 0005710|
|2019-11-16 18:41||Christian Grothoff||Target Version||0.12.0 => 0.13.0|
|2020-04-22 17:22||schanzen||Target Version||0.13.0 => 0.14.0|
|2020-08-14 12:01||schanzen||Tag Attached: tng|
|2020-10-28 13:06||schanzen||Target Version||0.14.0 => 0.15.0|
|2021-06-10 19:36||schanzen||Target Version||0.15.0 => 0.16.0|
|2021-12-31 09:29||schanzen||Target Version||0.16.0 => 0.17.0|
|2021-12-31 09:32||schanzen||Target Version||0.17.0 => 1.0.0|