Private networks aren't really private

[WinstonPrivacy]

We are using the go-ethereum p2p library, discv4 and a custom protocol. We have determined that the recommended method for creating a private network doesn't really work.

Specifically, the p2p/protocols library permits you to assign a version # to your protocol. Nodes that do not agree on protocol or version will not negotiate an RLPx handshake, which is good.

However, we have traced the code down to the p2p/discover library and found that nodes will still respond to ping, pong and findnode packets from peers which do not agree on RLPx protocol or version. This is bad.

Given the above, it seems almost trivial to write an ethereum powered crawler which can determine the existence of all ethereum nodes which are connected to the internet.

Please let me know if I am incorrect in this understanding. It would be excellent news to hear that ethereum nodes can be configured to respond only to other nodes on a private network and not to unknown peers (potential attackers).

[WinstonPrivacy]

##15358

[holiman]

I think it's a fair assessment that private networks aren't private. It's in the basic design. Correct, @fjl ?

[WinstonPrivacy]

I have also confirmed that hashing the discoverv4 packets isn't effective on its own either. While this will prevent node discovery, it does nothing to protect the RLPx protocol from being probed on a node. With the appropriate patches in place, we have been able to create private (undiscoverable) networks using the Ethereum p2p protocol. I'm surprised this hasn't been rolled in yet.

…

On Wed, Apr 3, 2019 at 2:46 PM Martin Holst Swende ***@***.***> wrote: I think it's a fair assessment that private networks aren't private. It's in the basic design. Correct, @fjl <https://github.com/fjl> ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#19378 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ai89gfQEniIgcT4RwypmlBUnRbgtbBQmks5vdQUAgaJpZM4cZNXi> .

[fjl]

The purpose of the discovery protocol is finding all the other nodes on the Internet. The term 'private network' is commonly used to describe non-mainnet blockchains but doesn't imply that the participants can't be discovered. If you fork the discovery to create your own small DHT and run it on the Internet, your system will have low security because small DHTs can be overtaken easily.

You have several options for peer discovery in a private chain setting:

• If you run a network with few, known participants just connect everyone together with static nodes and disable the DHT using --nodiscover.
• If your network runs within a single cloud environment, use --netrestrict or just close the firewall.
• If you need communication among multiple parties, set up a VPN with dedicated IP range, then run all clients with the --netrestrict flag to only allow communication with nodes in that range.

[WinstonPrivacy]

That's only true if one is using the higher level crypto protocols. You also forgot option #4, which is pretty easily implemented. Salt the discovery and RLPx handshakes so that packets not coming from authorized nodes are dropped. This can be implemented as an optional parameter and thus is completely backwards compatible without requiring any changes for existing users. This is an easy solution with no downside and I find it curious that it hasn't been implemented.

…

On Fri, May 3, 2019 at 7:13 AM Felix Lange ***@***.***> wrote: Pasting same response to the other issue. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#19378 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIXT3AIV7FHSTYU3HNGI6S3PTQT6TANCNFSM4HDE2XRA> .