p2p sends local-scope addresses when IPv4 is behind NAT

luke-jr commented at 7:54 pm on August 27, 2016: member

Wireshark tells me I am sending my local-scope IPv6 address, when connecting over IPv4 (behind NAT)… :/

Context: #8594

jonasschnelli added the label Priority Medium on Aug 30, 2016

jonasschnelli added the label P2P on Aug 30, 2016

laanwj added the label Privacy on Aug 31, 2016

laanwj commented at 2:10 pm on August 31, 2016: member

Added privacy tag. Leaking internal addresses behind a NAT is a serious privacy issue, see #8594 (comment) . Aren’t local-scope addresses based on the MAC address? Ouch.

laanwj added this to the milestone 0.13.1 on Aug 31, 2016

sipa commented at 10:36 am on September 1, 2016: member

@luke-jr Is this an RFC4862 address (fe80::/64) ?

luke-jr commented at 10:48 am on September 1, 2016: member

Hmm, no. I don’t seem to actually have the address on any of my interfaces.

Begins with fd87. Second-guessing if this is actually IPv6 local, or perhaps some way of encoding a Tor hidden service?

sipa commented at 11:20 am on September 1, 2016: member

Yes, that’s an onioncat address - the way Bitcoin P2P encodes onion addresses in IPv6.

sipa commented at 11:38 am on September 1, 2016: member

Closing; feel free to reopen if you see other local addresses being relayed.

sipa closed this on Sep 1, 2016

laanwj commented at 1:17 pm on September 1, 2016: member

Sending an onion address as from-address is a privacy breach, too.

sipa commented at 1:29 pm on September 1, 2016: member

Hmm, I believe the logic is that we send the most compatible known local address to peers. That means that you’d send your onion address to non-tor peers if you don’t know of any other local reachable non-onion address.

Perhaps that logic should be revisited, and we should never send an address out except to peers that are already connected to through that interface. That is complicated, as it means we need a way to identify incoming onion connections as belonging to tor.

sipa reopened this on Sep 1, 2016

laanwj commented at 1:34 pm on September 1, 2016: member

I think it should leave the addrFrom address blank in version messages, full stop. There’s no need to fill it in at all it if it’s no longer needed by peers connected to (e.g. #8594).

sipa commented at 1:35 pm on September 1, 2016: member

@laanwj Perhaps, but that’s orthogonal. We also announce our own address using ADDR messages.

laanwj commented at 1:36 pm on September 1, 2016: member

Which is less privacy-sensitive, at least it’s hiding among a crowd there.

EthanHeilman commented at 3:03 pm on September 8, 2016: contributor

Is anyone working on a PR for this? If I’m not stepping on anyone’s toes I’d like to put a PR together over the weekend.

laanwj commented at 9:28 am on September 13, 2016: member

@EthanHeilman not aware of anyone working on this

laanwj referenced this in commit d9c99c3058 on Sep 15, 2016

luke-jr referenced this in commit 42ea51a65f on Sep 21, 2016

laanwj commented at 5:12 am on September 22, 2016: member

Partially mitigated by #8740, removing 0.13.1 milestone.

laanwj removed this from the milestone 0.13.1 on Sep 22, 2016

OlegGirko referenced this in commit e666114da5 on Aug 31, 2017

UdjinM6 referenced this in commit 589d22f2ca on Sep 1, 2017

laanwj removed the label Priority Medium on Dec 6, 2017

Fuzzbawls referenced this in commit c79ac2ada9 on Aug 19, 2020

Fuzzbawls referenced this in commit fe12ff96ab on Aug 25, 2020

maflcko commented at 2:51 pm on August 5, 2022: member

Is this still an issue with a recent version of Bitcoin Core? If yes, what are the steps to reproduce?

vasild commented at 3:49 pm on July 10, 2023: contributor

To summarize, there are 3 issues here:

The problem from OP of sending local-scope addresses to peers was nonexistent. That was never done.
Sending our addr in the VERSION message, fixed by #8740
Sending our addr via ADDR (or ADDRv2) message. I need to look at this more carefully, but a brief look tells me that maybe the problem exists. I mean sending our IPv4 address to a Tor peer or sending our Tor address to an IPv4 peer. At least CNetAddr::GetReachabilityFrom() does not explicitly disable that:

https://github.com/bitcoin/bitcoin/blob/c464e67e0b71c397f6b3d3a920d98a1a2a296c7a/src/netaddress.cpp#L773

Maybe this can happen if we can make outbound connections to both Tor and IPv4 but only listen on one of them.

vasild commented at 9:03 am on August 17, 2023: contributor

#27411 should have resolved 3.

Thus, I think this issue can be closed as “fixed”.

willcl-ark commented at 8:06 pm on April 6, 2024: contributor

Closing as fixed based on prior comments from vasild.

willcl-ark closed this on Apr 6, 2024

p2p sends local-scope addresses when IPv4 is behind NAT #8616