net: option to disallow v1 connection on ipv4 and ipv6 peers

stratospher commented at 12:23 pm on September 23, 2024: contributor

resolves #29618.

This PR adds a config flag option -v2onlyclearnet which disallows v1 connections on ipv4 and ipv6 networks since they’re unencrypted. v1 connections are still possible from tor/i2p/cjdns peers since they’re encrypted networks.

v1 outbound connections to peers are not attempted
v1 reconnections are not attempted (if peer is falsely advertised as v2 peer and we attempt a v2 connection but it fails, we do not attempt a v1 reconnection when -v2onlyclearnet is switched on)
v1 inbound connections are immediately disconnected

Currently 59.71% of network supports v2 (according to https://bitnodes.io/nodes) so don’t see risk of network partition with the option set as default off. Also found 41-45 % of addresses supporting v2 in the addrman of nodes I checked - personal node and the nodes in peer.observer. (You can use this branch to check the % of v2 addresses in a node’s addrman.)

net: add option in CConman to disable v1 clearnet connections

a boolean option `disable_v1conn_clearnet` is introduced in CConman
which will (in a later commit) store if the user wishes to disable
v1 connections on IPV4 and IPV6 networks since they are unencrypted.

this option is accessible outside CConman using
`DisableV1OnClearnet()` function with the network we're trying to
connect to passed as an argument.

ac90b05a47

init: add -v2onlyclearnet config option

if this option is set by the user, v1 connections on unencrypted
networks like IPV4/IPV6 will be disallowed. Only users with real
need are recommended to turn this on because it could risk network
partitioning in the unlikely scenario that everyone turns it on.

a9d21f6cd8

DrahtBot commented at 12:23 pm on September 23, 2024: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept NACK	vasild
Concept ACK	mzumsande, dergoegge

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#30988 (Split CConnman by vasild)
#30885 (scripted-diff: Modernize nLocalServices naming by fjahr)
#29418 (rpc: provide per message stats for global traffic via new RPC ‘getnetmsgstats’ by vasild)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

DrahtBot added the label P2P on Sep 23, 2024

DrahtBot added the label CI failed on Sep 23, 2024

net: disable v1 connections, reconnections on clearnet

if `-v2onlyclearnet` is turned on,
- v1 addresses from addrman aren't selected and manual connections
aren't attempted for outbound connections if it's from IPV4/IPV6
networks.
- v1 downgrade mechainm is not attempted if v2 connection wasn't
successful

e78c0908e2

stratospher force-pushed on Sep 24, 2024

DrahtBot removed the label CI failed on Sep 24, 2024

stratospher force-pushed on Sep 25, 2024

test: Check that v1 connections to clearnet peers don't work

when `-v2onlyclearnet` is turned on:
- v1 connections to clearnet peers don't work
- v2 connections to clearnet peers work
- v1 conneections to tor/i2p/cjdns peer works

a proxy is used because otherwise NET_UNROUTABLE is the default
network in the tests.

ab5f8759ab

stratospher force-pushed on Sep 25, 2024

vasild commented at 4:40 pm on September 26, 2024: contributor

In #29618 and here, I don’t see the motivation to forbid v1 connections. In other words, what is the purpose of this?

In addition to the concerns expressed in #29618, there is one more - if V2-only is widespread, it may be hard to eclipse V2-only node, but then it becomes easy to eclipse a V1 node which has a problem of finding peers to connect to, so an attacker starts a lot of nodes that do accept V1 connections.

I see possible downsides and 0 benefit of a v2only option.

mzumsande commented at 3:54 pm on September 27, 2024: contributor

Concept ACK

In #29618 and here, I don’t see the motivation to forbid v1 connections.

Well, to gain the benefits of BIP324. For example if you are concerned about someone inspecting the traffic to your node it really doesn’t matter how many BIP324 peers you have if you have just one unencrypted connection. You could also run tor-only in this case, but that has its own disadvantages and -onlynet=onion shares the exact same downside that if everyone did it, the network would split. If some, but not all nodes who are running only on privacy networks would be willing to also have clearnet peers with this option, that would be a good thing in my opinion.

if V2-only is widespread

that would be a problem, but -onlynet, -blocksonly etc. have that exact same problem. I see this as an option you would only choose if you actually need it because you are concerned about unencrypted traffic.

jonatack commented at 9:35 pm on September 27, 2024: member

You could also run tor-only in this case, but that has its own disadvantages and -onlynet=onion shares the exact same downside that if everyone did it, the network would split.

Our docs address this to an extent here and here. As those docs point out, -onlynet only affects outbound connections (not inbound and manual ones), and we suggest that it be used with multiple networks. My blog goes further into it here and here.

If some, but not all nodes who are running only on privacy networks would be willing to also have clearnet peers with this option, that would be a good thing in my opinion.

Agree. My node, for instance, runs over tor/i2p/cjdns and makes manual connections to trusted clearnet peers.

if V2-only is widespread, it may be hard to eclipse V2-only node, but then it becomes easy to eclipse a V1 node which has a problem of finding peers to connect to, so an attacker starts a lot of nodes that do accept V1 connections.

Agree. With this change, clearnet node operators may need to accept v2, whether they wish to or not. We generally try to avoid forcing users to do things. I suppose my concept ack on this would depend on that tradeoff.

vasild commented at 4:28 am on September 28, 2024: contributor

For example if you are concerned about someone inspecting the traffic to your node it really doesn’t matter how many BIP324 peers you have if you have just one unencrypted connection.

True. Lets dive a bit deeper - what are the reasons to be concerned about somebody inspecting the traffic to my node?

in src/init.cpp:553 in ab5f8759ab

549@@ -550,6 +550,7 @@ void SetupServerArgs(ArgsManager& argsman, bool can_listen_ipc)
550     argsman.AddArg("-i2pacceptincoming", strprintf("Whether to accept inbound I2P connections (default: %i). Ignored if -i2psam is not set. Listening for inbound I2P connections is done through the SAM proxy, not by binding to a local address and port.", DEFAULT_I2P_ACCEPT_INCOMING), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
551     argsman.AddArg("-onlynet=<net>", "Make automatic outbound connections only to network <net> (" + Join(GetNetworkNames(), ", ") + "). Inbound and manual connections are not affected by this option. It can be specified multiple times to allow multiple networks.", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
552     argsman.AddArg("-v2transport", strprintf("Support v2 transport (default: %u)", DEFAULT_V2_TRANSPORT), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
553+    argsman.AddArg("-v2onlyclearnet", strprintf("Disallow v1 connections on IPV4/IPV6 (default: %u). Enabling this is not recommended unless absolutely necessary, as it may risk network partitions if all users enable it.", false), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);

jonatack commented at 1:21 pm on September 28, 2024:

Enabling this is not recommended unless absolutely necessary, as it may risk network partitions

This is unfortunately only one brigading campaign by one or more prominent bitcoiners on social media away from being potentially adopted by many nodes.

With -onlynet, the network partition risk is in practice opt-in, i.e. chosen by a minority subset for themselves. Whereas here, the network partitioning and the lack of peers risks could be imposed on a future minority of users that are running earlier versions of Bitcoin Core. This seems at odds with maintaining backward compatibility for that minority.

in src/net.h:1583 in ab5f8759ab

1576@@ -1572,6 +1577,13 @@ class CConnman
1577      */
1578     bool whitelist_relay;
1579 
1580+    /**
1581+     * option for disabling v1 connections on IPV4 and IPV6.
1582+     * connections on IPV4/IPV6 need to be v2 connections.
1583+     * connections on Tor/I2P/CJDNS maybe v1 or v2 connections.

jonatack commented at 1:22 pm on September 28, 2024:

“may be” or “can be”

0     * connections on Tor/I2P/CJDNS can be v1 or v2 connections.

mzumsande commented at 7:54 pm on September 28, 2024: contributor

True. Lets dive a bit deeper - what are the reasons to be concerned about somebody inspecting the traffic to my node?

Some thoughts off the top my head:

You don’t want others (e.g. network admins, internet providers, etc.) to know that you are running a bitcoin node at all. Maybe it’s not allowed in your network / country etc., maybe for other reasons such as personal security.
Transaction privacy

In both of these cases, if you accept inbounds they could just connect to you as an alternative (but they would need to have a suspicion, whereas detection of bitcoin-related network data could be automated). So another alternative would be to only disallow v1 connections for outbound peers. In that case, if you don’t want any v1 connections at all you’d have to run with -nolisten.

DrahtBot added the label CI failed on Sep 29, 2024

DrahtBot removed the label CI failed on Sep 29, 2024

vasild commented at 4:51 pm on September 29, 2024: contributor

what are the reasons to be concerned about somebody inspecting the traffic to my node?

You don’t want others (e.g. network admins, internet providers, etc.) to know that you are running a bitcoin node at all. Maybe it’s not allowed in your network / country etc., maybe for other reasons such as personal security.

This is what is worrying me - V2-only will not hide the fact that I am running a bitcoin node, but may give the false impression that it does. This is dangerous. My node will connect to publicly known bitcoin nodes and the mere fact that I have a TCP connection to an addr:port, where it is known that a bitcoin node is running, is already revealing enough. No need to inspect the traffic itself.

Another possible misunderstanding is that V2-only makes the traffic impossible to spy. I can imagine a blatant MITM, which is detectable because the session keys would differ, should somebody bother to check them. Once I detect this, whom am I going to complain to? My oppressive gov/ISP/whatever, same one that is doing the spying? Or the ISP can outright redirect my connections to addr:port to their spy node at spyaddr:port (I think I am talking to addr, but addr does not even have a connection from me). The point is that the traffic is spyable. Then, what is it so much that I want to keep away from spies? The data being transferred is all public, except if we are talking about me broadcasting my own transactions, there you go:

Transaction privacy

V2-only may give the false impression that it breaks the link between transaction origin and IP address / geolocation. Even with unspyable p2p encryption, I may have a connection to a spy bitcoin node which then sees my traffic. Like you said “it really doesn’t matter how many BIP324 peers you have if you have just one unencrypted connection” I think this is the same as “it does not matter even if all your connections are encrypted, if you have just one (encrypted) connection to a spy node”.

stratospher commented at 6:20 pm on September 29, 2024: contributor

@vasild V2 only doesn’t protect against active attacks like the ones you’ve mentioned which require resources from the other party to run a node to spy the traffic.

V2 only protects against a cheaper attack vectors possible because of passive inspection of network traffic flowing through different medium. They don’t need the other party to run a node to spy.

True. Lets dive a bit deeper - what are the reasons to be concerned about somebody inspecting the traffic to my node?

Some thoughts off the top my head:

You don’t want others (e.g. network admins, internet providers, etc.) to know that you are running a bitcoin node at all. Maybe it’s not allowed in your network / country etc., maybe for other reasons such as personal security.

Transaction privacy

Yes, for the same reason as wanting to encrypt network traffic in the first place and this just offers a stronger guarantee when running a node with v2 support that unencrypted clearnet bitcoin traffic is not being collected and sold by other parties. Deep packet inspection, keyword filtering are cheaper for ISPs/firewalls to pull off and v2 only would protect against this.

vasild commented at 11:53 am on October 2, 2024: contributor

A V2-only option will:

not hide the fact that one runs bitcoin node (that is true regardless of encryption) and
not stop even moderately motivated actor from spying for transaction origin (either by opening a P2P connection to the target or bricking V2 encryption or outright redirecting connections to their node)

but it will give the false impression that it does those two things. Further, it will make it more difficult for old nodes to find peers to connect to.

Concept NACK because of that.

dergoegge commented at 12:45 pm on October 2, 2024: member

Concept ACK

This option seems useful for users that want to:

prevent passive spying on their connections
increase the cost of tampering with the data exchanged on their connections
increase the cost of detecting that they run a bitcoin node

Currently 59.71% of network supports v2

Have you checked how diverse these ~60% of v2 supporting nodes are? An extreme example: if they are all on running on AWS then I don’t think we should add the option at this time.

vasild commented at 2:19 pm on October 2, 2024: contributor

increase the cost of detecting that they run a bitcoin node

How? Given that the spy does not need to inspect the traffic at all:

My node will connect to publicly known bitcoin nodes and the mere fact that I have a TCP connection to an addr:port, where it is known that a bitcoin node is running, is already revealing enough.

sipa commented at 2:27 pm on October 2, 2024: member

@vasild That assumes the attacker has sufficient monitoring infrastructure in place to maintain an accurate list of Bitcoin P2P ip:ports. That’s obviously not impossible, but it is a significantly larger effort than stateless packet inspection looking for the string “\xf9\xbe\xb4\xd9version\x00\x00\x00\x00\x00”.

And yes, very little in BIP324 protects against an attacker deliberately targetting specific individuals - its goal is increasing costs for large-scale monitoring. From that perspective I agree there is a risk for a false sense of security when introducing options like these, but I think it’s a stretch to say that that makes it pointless. I can very well imagine this makes it possible to run a node at all for some users.

However, as I pointed out in the linked issue, I am somewhat concerned about a potential future where it becomes harder for other/older software to connect to the network if large swaths move to be v2-only. Because of that, I wonder if it isn’t better to make this only apply to outbound connections, and advise people who want more private operation to not listen for inbound connections.

jonatack commented at 2:59 pm on October 2, 2024: member

However, as I pointed out in the linked issue, I am somewhat concerned about a potential future where it becomes harder for other/older software to connect to the network if large swaths move to be v2-only. Because of that, I wonder if it isn’t better to make this only apply to outbound connections, and advise people who want more private operation to not listen for inbound connections.

Yes. I may be potentially concept/approach ack here if this proposal adopts the suggestion above / in #29618 (comment) or #29618 (comment). (Along with perhaps additional user documentation for node runners, maybe in the relevant config option helps and/or in /doc.)

1440000bytes commented at 9:15 pm on October 3, 2024: none

I think it’s too early to add this option but it will remain unused by most and off by default. I don’t see anything wrong with some users testing it.

This doesn’t hide the fact that a user is running a bitcoin node (most IPv4 nodes use default port). It just ensures all peers are using v2 for P2P.

net: option to disallow v1 connection on ipv4 and ipv6 peers #30951

Code Coverage

Reviews

Conflicts