Questions about thesecretlivesofdata HOT 8 CLOSED

Specifically https://github.com/rqlite/rqlite/blob/master/DOC/SECURITY.md

But this is a feature of rqlite, not Raft itself.

from thesecretlivesofdata.

I can answer 2. Raft assumes behaving nodes -- it is not designed to deal with a node that is deliberately trying to circumvent the system.

from thesecretlivesofdata.

And if a node tries to circumvent the system that is considered a bug in the implementation, not an "attacker".

from thesecretlivesofdata.

@otoolep thanks for the quick reply. Isn't assuming that all nodes are honest a bit naive ? If the project is open source, one could re-engineer a tainted version that could connect itself to the network. Even if not open source, reverse engineering exists. And if all nodes are guaranteed to be well-behaving, there's still the risk of having a man-in-the-middle usurper modifying for example Append entries messages (probably harder if messages are properly encrypted though).

Then, are there guidelines / recommendations on how to safely implement this consensus ?
Guess I'll have to find some time and dig in some implementations.

from thesecretlivesofdata.

It's not naive. Like any system you are responsible for running a secure deployment and network, and only standing up nodes with software you trust. If your network is so open that nodes you can't control can just connect, you may have bigger issues.

However many actual usages of Raft consensus protocol -- my own rqlite system for example -- do allow you to enable security checks, requiring nodes that wish to join to supply the right password. That way you only supply the password to the nodes you trust. The easiest way to do this is to only supply the password to nodes you launch.

from thesecretlivesofdata.

I see. Thanks for the support, closing this issue !

from thesecretlivesofdata.

For example, if you know the IP addresses of which nodes are running your Raft system, you might be able to configure your network such that only those nodes can talk to each other, for the purposes of joining. This would prevent any other node from connecting.

This is an example of what I mean by a "secure deployment and network". AWS EC2 Security Groups, for one, allow you to do this. (https://github.com/rqlite/rqlite/blob/master/DOC/SECURITY.md#network-security)

from thesecretlivesofdata.

yeah... it's a bit different for blockchain systems (no control over the network), where whitelisting IP addresses would be a terrible idea. I suppose I was too focused on this example :)

from thesecretlivesofdata.