Verify that public websocket API does not expose sensitive API calls

[bytemaster]

1. network_api::add_node
2. network_api::get_connected_peers

These calls need to remain available only for authenticated connections.

[VoR0220]

how far do our authentication efforts have to go? I assume this is trying to prevent an Eclipse attack...but what should the user have to give up in order to (attempt to) ensure that they aren't a bot in the network? Perhaps hard coding in witnesses/delegates/workers IP address would help prevent an Eclipse attack from taking over the entire routing table of a user?

[nathanielhourt]

This isn't about eclipse attacks, it's just about preventing an unauthorized party from seeing or modifying sensitive node state.

[jcalfee]

For a hosted wallet, the public API is probably best as a whitelist file where each call is added on case-by-case basis and reviewed for its potential to return too much data, run slow, etc... Even though a call may be safe it is not added to the whitelist until it is looked at and needed. This limits exposure to unknown bugs.

[theoreticalbts]

@jcalfee -- This is the purpose of having multiple API's in the RPC infrastructure. Functions are whitelisted for public use by registering the API's containing those functions to anonymous connections.

The problem is that the way functions are currently categorized into API's has some API's with a mix of public methods (safe for public access and needed by hosted wallet) and private methods (unsafe for public access).

[VoR0220]

@theoreticalbts @nathanhourt Could you elaborate on the problem that could happen if a node gathers another node's peer list and makes a request for a connection endpoint?

[nathanielhourt]

@VoR0220 An eclipse attack is a reasonable exploit of the vulnerability, but it's a more general issue. I might not want third parties knowing how my network is organized. I certainly don't want third parties controlling which nodes I am connected to.

[VoR0220]

Might one way to solve this be to set it up so that a request only gives you a quarter of the nodes in the list and from there get a quarter from all the other nodes in the list?

[nathanielhourt]

The solution is simply to reject access to the network API until the client authenticates.

[VoR0220]

@nathanhourt I've been trying to find ways to authenticate in a p2p network....any ideas so far about how we go about authenticating the client?

[theoreticalbts]

@nathanhourt The problem is that public [1] access for broadcasting tx's is desirable (maybe with some rate limiting), but access to add_node should definitely be restricted to node admins.

@VoR0220 Authenticating in a p2p network is a hard problem, which likely ultimately requires some form of p2p PKI (public key infrastructure), i.e. some shared global database mapping entities to pubkeys. Which is a major purpose of the account systems in BitShares 0.x or Graphene. You can also view tx signatures (in any cryptocurrency) as a form of p2p authentication -- itself a kind of PKI. (E.g. in Bitcoin, the script attached to a balance maps an entity -- the owner of that specific balance -- to a pubkey.)

[1] Either truly public anonymous access, or access by ordinary user account (i.e. the account you get if you sign up with a hosted wallet provider as a member of the general public).

[nathanielhourt]

Then split the network API into separate APIs -- one for public access and one for administrative access.

[VoR0220]

@theoreticalbts when you say node admins, are you referring to an authority type? Or might you be referring to a witness? Just looking for elaboration.

[theoreticalbts]

@VoR0220 By "node admin," I was referring to the system administrator of the machine where the node is running.

[theoreticalbts]

I'm going to take over this ticket. It is clear that we need to simply split the network API into two different API's.

[VoR0220]

damn...I kind of wanted to try my hand at this....

[theoreticalbts]

We still need to audit all calls and review, for each call, why public access is safe.

[vikramrajkumar]

This TODO also needs to be addressed:

graphene/libraries/app/application.cpp

Lines 231 to 240 in a751d90

	// TODO: Remove this generous default access policy
	// when the UI logs in properly
	_apiaccess = api_access();
	api_access_info wild_access;
	wild_access.password_hash_b64 = "*";
	wild_access.password_salt_b64 = "*";
	wild_access.allowed_apis.push_back( "database_api" );
	wild_access.allowed_apis.push_back( "network_broadcast_api" );
	wild_access.allowed_apis.push_back( "history_api" );
	_apiaccess.permission_map["*"] = wild_access;

[vikramrajkumar]

This issue was moved to bitshares/bitshares-core#33