RFC: bad ports

[Sjors]

#23306 and #23542 let nodes connect (more often) to other ports than 8333.

@practicalswift brought up a concern:

A third concern (which I think can be addressed: see below) could be that Bitcoin Core users would risk having to deal with bogus complaints along the lines of "why am I seeing a failed SSH-login to my server on port 22 from your IP-address w.x.y.z?" if we allowed for automatic outgoing connections on all ports by default.

When opening up for additional port numbers we might want to look at how browsers are tackling "bad ports":

• kRestrictedPorts in Chromium
• gBadPortList in Firefox
• Definition of "bad port" in whatwg's Fetch standard

Avoiding "bad ports" (or a subset of these ports) by default is probably a cheap way to reduce the likelihood of Bitcoin Core users having to deal with these types of bogus complaints.

This has been addressed in the second PR, by introducing "bad ports" that we don't connect to unless we're running out of other options.

In order not to invite a nit-war on that PR, I figured it would be good to discuss the list of ports here, so we can tweak it (now, but also in the more distant future).

General note from @sipa about expanding the list #23542 (comment):

Adding entries to the list may be undesirable, as it may mean that someone running a node on such a port silently stops getting connections.

Not a very serious concern, as this would happen spread over some amount of time anyway, but still a reason I think to err on the side of caution and start with a possibly overly expansive list here

---

My first suggestion would be to add ports 21 (ftp), 80 (http) and 443 (https). These are obviously not considered bad by browsers, but they are most certainly monitored by paranoid system administrators. Some websites are totally off limits for unauthenticated users. And they are heavily logged.

Conversely though, there may be a good reason to have a Bitcoin node listen on port 80, because firewalls won't block it. But we could handle that with special-case connection code, e.g. if we notice all our outbound connection attempts fail, and we've tried nodes from the bad list and those fail too, we specifically look for port 80/443 nodes in our list. We'll need special case code anyway if we ever want to mask our traffic as regular HTTP.

[ghost]

In order not to invite a nit-war on that PR, I figured it would be good to discuss the list of ports here, so we can tweak it (now, but also in the more distant future).

Makes sense

My first suggestion would be to add ports 21 (ftp), 80 (http) and 443 (https). These are obviously not considered bad by browsers, but they are most certainly monitored by paranoid system administrators. Some websites are totally off limits for unauthenticated users. And they are heavily logged.

21 is already added. Not sure about others.

I think we should merge that pull request with current "bad ports" list so that it works only for testnet and signet in v23.0. I am not sure if this approach is used for anything in past but this would allow us to fix issues (if any) without discussing "bad ports" list forever.

There was no objection or feedback on mailing list as well.

[willcl-ark]

Close as resolved