1. 14

distkv is a distributed K/V store library for Go powered by the raft consensus algorithm. Values are only changed when a majority of nodes in the cluster agree on the operation. Internal communication is secured and powered by the SSH protocol.

It ensures confidentiality and security by enforcing asymmetric authentication and encryption using the SSH protocol. A custom built interface leveraging the protocols features (TCP/IP forwarding and out-of-band requests) secures all raft and control communication.

SSH was chosen over TLS because it provides strong, battle tested security without needing centralized third-party trust authorities. This makes it a good fit for distributed systems like distkv.

I developed this recently and was inspired by the “Why aren’t we using SSH for everything” thread to share this project with you (thanks for the invite @rain1).

  1.  

  2. 2

    SSH was chosen over TLS because it provides strong, battle tested security without needing centralized third-party trust authorities. This makes it a good fit for distributed systems like distkv.

    FWIW, nothing about TLS requires third-party CAs. It’s entirely possible to use TLS (esp. with crypto/tls) with a Trust On First Use (TOFU) model. SSHv2 is still a fine choice, provided you’re using a modern configuration (and since you’re using golang.org/x/crypto/ssh, you are).

    1. 1

      FWIW, nothing about TLS requires third-party CAs

      You are right in this regard, the third-party attribute is not necessarily given, but I’d argue it is true most of the time. Any proper CA - even if you run it yourself (which has its own security implications) - will usually be centralized again for security reasons and would therefore contradict the distributed approach.

      It’s entirely possible to use TLS (esp. with crypto/tls) with a Trust On First Use (TOFU) model

      I wanted to implement a simple to use, security first approach. Automated TOFU is basically useless for MITM protection, it’s like not even checking the host key fingerprint upon your first SSH connection. TLS would have required distributon of all node certificates for the decentralized (self-signed) use case, so I did not see a simplification.

      1. 1

        Automated TOFU is basically useless for MITM protection, it’s like not even checking the host key fingerprint upon your first SSH connection.

        SSHv2 uses a TOFU model, and it’s about as automated as they come. You’re correct that if the first connection is MitM’d, then the “trust” aspect of it falls apart. But that’s an intentional tradeoff of this approach. OpenSSH recently added support for CA-signed host keys to work around this exact issue.

        TLS would have required distributon of all node certificates for the decentralized (self-signed) use case, so I did not see a simplification.

        TLS does not require pre-distributed certificates. You can compute a fingerprint of the certificate used in the handshake and compare it to the fingerprint of the certificate used in the last handshake—exactly like SSHv2. I’ve implemented a system exactly like this in Go.

        1. 1

          SSHv2 uses a TOFU model, and it’s about as automated as they come. You’re correct that if the first connection is MitM’d, then the “trust” aspect of it falls apart.

          Unfortunately, many end-users and even companies are very careless in this aspect - e.g. my experience with some server providers shows it may even be impossible to securely bootstrap a system with them (no fingerprint given). But I think we are on the same page here - it always comes down to some trade off between security and usability.

          OpenSSH recently added support for CA-signed host keys to work around this exact issue.

          Interesting, I am going to take a look at the implementation!

    2. [Comment removed by author]

      1. 1

        Thank you!