View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003896GNUnettransport servicepublic2015-07-17 01:192024-10-11 11:15
Reporterdangole Assigned Tot3sserakt  
PrioritynormalSeverityfeatureReproducibilityalways
Status assignedResolutionopen 
Platformany 
Product VersionGit master 
Target Version1.0.0 
Summary0003896: GNUnet HELLOs break privacy, especially on IPv6
DescriptionGNUnet'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 ReproduceInstall GNUnet. Oops, I just leaked my hardware MAC addresses...
Tagstng
Attached Files

Relationships

related to 0005710 confirmed TNG meta issue 
related to 0009253 new udp-communicator is talking to itself 

Activities

Christian Grothoff

2015-07-17 22:54

manager   ~0009462

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.

dangole

2015-07-18 22:29

developer   ~0009465

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

dangole

2016-01-15 11:08

developer   ~0010055

Last edited: 2016-01-15 11:11

 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.

lynX

2016-01-23 02:01

developer   ~0010087

Last edited: 2016-01-23 02:04

 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?

lynX

2016-01-23 02:03

developer   ~0010088

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.

Christian Grothoff

2016-01-23 11:11

manager   ~0010089

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

Christian Grothoff

2016-01-23 11:12

manager   ~0010090

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.

lynX

2016-01-23 14:38

developer   ~0010091

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.

dangole

2016-01-27 09:50

developer   ~0010104

Last edited: 2016-01-27 09:51

 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.

dangole

2016-12-02 00:23

developer   ~0011560

partially adressed by https://gnunet.org/git/gnunet.git/commit/?id=6aa3cedfa5e9df7aacbbdcf62c977e09b0e7f6c3

redfish

2018-08-04 22:12

reporter   ~0013173

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)   

Issue History

Date Modified Username Field Change
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
2024-03-15 13:50 schanzen Assigned To => t3sserakt
2024-03-15 13:50 schanzen Status confirmed => assigned
2024-10-11 11:15 schanzen Relationship added related to 0009253