Verify that public websocket API does not expose sensitive API calls

[vikramrajkumar]

From @bytemaster on June 30, 2015 20:54

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

These calls need to remain available only for authenticated connections.

Copied from original issue: cryptonomex/graphene#118

[vikramrajkumar]

From @VoR0220 on July 1, 2015 0:58

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?

[vikramrajkumar]

From @nathanhourt on July 1, 2015 14:20

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

[vikramrajkumar]

From @jcalfee on July 1, 2015 15:48

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.

[vikramrajkumar]

From @theoreticalbts on July 1, 2015 16:15

@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).

[vikramrajkumar]

From @VoR0220 on July 1, 2015 21:42

@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?

[vikramrajkumar]

From @nathanhourt on July 2, 2015 16:18

@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.

[vikramrajkumar]

From @VoR0220 on July 2, 2015 18:36

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?

[vikramrajkumar]

From @nathanhourt on July 2, 2015 19:3

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

[vikramrajkumar]

From @VoR0220 on July 3, 2015 18:8

@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?

[vikramrajkumar]

From @theoreticalbts on July 6, 2015 2:26

@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).

[vikramrajkumar]

From @nathanhourt on July 6, 2015 13:57

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

[vikramrajkumar]

From @VoR0220 on July 6, 2015 16:27

@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.

[vikramrajkumar]

From @theoreticalbts on July 6, 2015 17:6

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

[vikramrajkumar]

From @theoreticalbts on July 6, 2015 17:52

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.

[vikramrajkumar]

From @VoR0220 on July 6, 2015 17:54

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

[vikramrajkumar]

From @theoreticalbts on July 8, 2015 18:4

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: https://github.com/cryptonomex/graphene/blob/a751d90e000903821ad8a096079d0bdb19f4f948/libraries/app/application.cpp#L231-L240

[abitmore]

This has been done.