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

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

2. jonasschnelli added the label Priority Medium on Aug 30, 2016
3. jonasschnelli added the label P2P on Aug 30, 2016
4. laanwj added the label Privacy on Aug 31, 2016
5. 
   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.
6. laanwj added this to the milestone 0.13.1 on Aug 31, 2016
7. 
   sipa commented at 10:36 am on September 1, 2016: member

   @luke-jr Is this an RFC4862 address (fe80::/64) ?
8. 
   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?

9. 
   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.
10. 
    sipa commented at 11:38 am on September 1, 2016: member

    Closing; feel free to reopen if you see other local addresses being relayed.
11. sipa closed this on Sep 1, 2016

    ---

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

    Sending an onion address as from-address is a privacy breach, too.
13. 
    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.

14. sipa reopened this on Sep 1, 2016

    ---

15. 
    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).
16. 
    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.
17. 
    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.
18. 
    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.
19. 
    laanwj commented at 9:28 am on September 13, 2016: member

    @EthanHeilman not aware of anyone working on this
20. laanwj referenced this in commit d9c99c3058 on Sep 15, 2016
21. luke-jr referenced this in commit 42ea51a65f on Sep 21, 2016
22. 
    laanwj commented at 5:12 am on September 22, 2016: member

    Partially mitigated by #8740, removing 0.13.1 milestone.
23. laanwj removed this from the milestone 0.13.1 on Sep 22, 2016
24. OlegGirko referenced this in commit e666114da5 on Aug 31, 2017
25. UdjinM6 referenced this in commit 589d22f2ca on Sep 1, 2017
26. laanwj removed the label Priority Medium on Dec 6, 2017
27. Fuzzbawls referenced this in commit c79ac2ada9 on Aug 19, 2020
28. Fuzzbawls referenced this in commit fe12ff96ab on Aug 25, 2020
29. 
    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?
30. 
    vasild commented at 3:49 pm on July 10, 2023: contributor

    To summarize, there are 3 issues here:

    1. The problem from OP of sending local-scope addresses to peers was nonexistent. That was never done.
    2. Sending our addr in the VERSION message, fixed by #8740
    3. 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.

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

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

    Closing as fixed based on prior comments from vasild.
33. willcl-ark closed this on Apr 6, 2024

    ---

Contributors
luke-jr laanwj sipa EthanHeilman maflcko vasild willcl-ark

Labels
P2P Privacy