Thoughts on SHA-256 hash for device verification

(David Goodenough) #1

According to the Docs / Security Principles page at when machines becomes known to each other, they both send the SHA-256 hash of their respective cert.pem’s, which are then used for verification on subsequent connections.

It’d be really nice when adding a new machine to my cluster if I could either:

  1. Get the public key pem files from all machines in the cluster and put them on the new machine, thus allowing it to auto accept the connection requests. Likewise by putting the new machine’s pem file on the other machines it would make the initial connection very easy.

  2. Somehow preload the SHA-256 hashes in the same way as the above, for the same reasons.

As a side note to this, is there any benefit or liability to providing an option to completely stop using SHA-256 certificate hashes, and instead allow the connection if and only if the remote machine’s public key is present.

Among other things, that should allow very quick and easy revocation of a machine in the event it’s key private files were compromised; simply delete the public keys from all systems and it is removed from the cluster.

(Audrius Butkevicius) #2

You can already do #2 by calling the rest api or modifying config.xml Public key only is fairly large compared to the hash, which complicates things such as discovery.

(Frederic Saladin) #3

Have you already had a look at the ‘introducer’ feature ? It’s not exactly what you’re looking for but might be helpful.

Documentation about the ‘introducer’ feature can be found on:

(Jakob Borg) #4

While this would be technically possible I’m not sure I see the advantage. Storing the keys is equivalent to storing their hashes. Removing the keys is about as simple as removing their hashes. Is the problem that you don’t want to change a config file or use the API?

You sort of need to do that anyway to define which folders to share with the devices.