Add whitelist support

[qdrn]

At some point it would be nice to add a whitelist option. You could provide a list of IP and connections from nodes corresponding to these IP would always be accepted.

[AureliaDolo]

You mean, when you are full, you disconnect another connection to connect to the whitelisted ip ?

[qdrn]

You mean, when you are full, you disconnect another connection to connect to the whitelisted ip ?

Either that, or you always keep some slots for whitelisted IPs. What's your take @damip ?

[damip]

Here is a possible spec:

• have a target_out_whitelisted_connections config param
• have a max_in_whitelisted_connections config param
• have a massa-node/config/whitelist_peers.json optional file (gitignored) containing a list of IPs
• in peer_db have a "whitelisted: bool" property in PeerInfo
• try to esablish target_out_whitelisted_connections towards whitelisted targets
• accept up to max_in_whitelisted_connections incoming connections from whitelisted IPs
• otherwise, whitelisted peers will behave similarly to bootstrap peers

Warning: node-node communications are not encrypted nor authenticated/signed. Whitelisted connections are sensitive to man-in-the-middle attacks and should NOT be trusted more than other connections

[AureliaDolo]

That seems like a lot, what's the real purpose of whitelisting ?

[damip]

That seems like a lot,

I already added something very similar for bootstrap peers, in order to ensure that our bootstrap nodes are always connected all together, and also that normal users don't make more than 1 connection towards a bootstrap node.

https://github.com/massalabs/massa/blob/main/massa-node/base_config/config.toml#L99-L102
https://github.com/massalabs/massa/blob/main/massa-network/src/peer_info_database.rs#L289-L293
etc...

It took 2 or 3 hours to implement

what's the real purpose of whitelisting ?

when there are some nodes you know about, and absolutely want to be connected to in order to ensure that you cannot be connected only to attackers (that can happen statistically, especially if attackers are advertising many IP addresses and simulating many nodes).

This feature is present in all major cryptos and heavily used.

[sebastien-forestier]

Do we need to whitelist IP+nodeID to prevent man in the middle ?

[damip]

Do we need to whitelist IP+nodeID to prevent man in the middle ?

Yes but it's not enough. To prevent MITM and replay attacks we need chained message authentication like we do for bootstrap. This adds overhead (eg. hashing every received message and verifying its signature)

[AureliaDolo]

I was more thinking about having a whitelist in the client that would mean, I want to to connect to this ip, even if it means dropping another connection. As for the persistence, I'm not really sure about that. @z80dev do you have any intake on what would be the best for this kind of feature ?

[damip]

I was more thinking about having a whitelist in the client that would mean, I want to to connect to this ip, even if it means dropping another connection. As for the persistence, I'm not really sure about that. @z80dev do you have any intake on what would be the best for this kind of feature ?

In the client ? Here it will only be happening in the node.

According to the spec above, it will behave just like we currently do with bootstrap node connections: it will not supersede any connections, the node will just try to always have a given number of extra whitelist connections active.

Persistence: same thing as bootstrap nodes. We could maybe go further and decide to have no file persistence for bootstrap and whitelist nodes.

[AureliaDolo]

Wait for #2297 to be merged and then

• add whitelisted_peers.json that is read at start up
• add whitelist [ip] client and api command that make a peer whitelisted (create it if non existant)
• add unwhitelist/make_standard/find_a_better_name [ip] client and api command that make a peer standard (create it if non existant)