TCP

[tdammers]

Some SPOs would prefer to not require opening up their node hosts to SSH.

Allowing kes-agent to exchange keys over TCP was suggested,however this would require solving encryption and authentication.

[tdammers]

Specific example scenario:

An SPO is currently running multiple block producing nodes, on separate hosts, and would prefer to not have to provision any additional hosts for a KES agent, instead using the existing hosts to run redundant KES agents.

This is possible in principle, but requires SSH connections between those hosts. However, for security reasons, the SPO wants to block SSH connections between hosts at the network level, to prevent attackers from escalating from one host to the others via SSH. They would prefer to connect to a KES agent through TCP, as that would only allow such an attacker to connect to a KES agent specifically, but not gain a shell or remote code execution.

[tdammers]

Some quick research on the feasibility of implementing TLS in KES Agent:

• Most TLS libraries on Hackage provide an API that uses ByteStrings to represent payloads. This is unacceptable for our purposes, because ByteStrings cannot be reliably mlocked. The following libraries all have this issue:
  • tls
  • network-conduit-tls
  • network-simple-tls
  • pipes-network-tls
  • tcp-streams
  • tcp-streams-openssl
• However, HsOpenSSL provides a pair of functions, writePtr and readPtr, that accept raw pointers to buffers, and we can use mlocked memory for those. These pointers appear to be passed through to the underlying OpenSSL C library as-is, but we still need to check whether OpenSSL uses any non-mlocked buffers of its own to encrypt and send these. HsOpenSSL also has the advantage of using a widely used, industry-strength TLS implementation (OpenSSL), rather than rolling its own cryptography in Haskell.

Hence, if we decide to implement this, then the proposed strategy would be:

• Add TLS support using HsOpenSSL; use the writePtr and readPtr functions to implement the RawBearer API for TLS connections.
• Use client certificates for authentication.
• To configure a KES agent for TCP, the following configuration must be provided:
  • A root CA store to bootstrap TLS
  • A server certificate (used to authenticate the KES agent against any clients)
  • A list of client certificates allowed to connect (used to authenticate clients against the KES agent)
  • A port number to listen on
• For a client to connect to a KES agent over TCP, the required configuration would be:
  • A root CA store to bootstrap TLS
  • A client certificate to authenticate against the KES agent
  • An address (host + port) to connect to