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

issue luke-jr opened this issue on August 27, 2016
  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: member

    Closing as fixed based on prior comments from vasild.

  33. willcl-ark closed this on Apr 6, 2024
  34. bitcoin locked this on Apr 6, 2025
Contributors
luke-jrlaanwjsipaEthanHeilmanmaflckovasildwillcl-ark
Labels
P2PPrivacy
Linked (view graph)
#8594 Do not add random inbound peers to addrman.#8740 net: No longer send local address in addrMe
github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-27 18:15 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me