Currently, slocky clients can only connect if they have the certificate generated by the server. Ideally the clients should not magically be able to access the directory which the server saves this information, so some mechanism should be in place to securely distribute the certificate to the client.
It has been recommended to me to do it like so:
1) initial authentication
a) administrator generates a phrase on the server, gives it to user
b) client opens a socket connection to the server.
c) server sends the cert to the client, and a salted checksum of the cert. The salt is the pharse given to the user in step a)
d) the client generates their own checksum via pass phrase, and if the checksums match, the client consideres the certificate to be trustworthy and saves the cert to the correct location on the file system.
e) the client opens a ssl wrapped socket connection to the server using the certificate.
f) the client sends the phrase to the server. If this phrase is expected, the server assigns a device id to the client and sends it to the client. This data is stored on both the client and server for future use.
g) all future data sent over ssl from the client contains this device id for both routing purposes as well as the possibility of the server revoking the id.
2) subsequent authentication
a) the client connects over ssl, and then sends a data chunk with it's device id
b) if the device id is ok for use in the server's records, then the server will communicate with the client normally.
Currently, slocky clients can only connect if they have the certificate generated by the server. Ideally the clients should not magically be able to access the directory which the server saves this information, so some mechanism should be in place to securely distribute the certificate to the client.
It has been recommended to me to do it like so:
1) initial authentication a) administrator generates a phrase on the server, gives it to user b) client opens a socket connection to the server. c) server sends the cert to the client, and a salted checksum of the cert. The salt is the pharse given to the user in step a) d) the client generates their own checksum via pass phrase, and if the checksums match, the client consideres the certificate to be trustworthy and saves the cert to the correct location on the file system. e) the client opens a ssl wrapped socket connection to the server using the certificate. f) the client sends the phrase to the server. If this phrase is expected, the server assigns a device id to the client and sends it to the client. This data is stored on both the client and server for future use. g) all future data sent over ssl from the client contains this device id for both routing purposes as well as the possibility of the server revoking the id.
2) subsequent authentication a) the client connects over ssl, and then sends a data chunk with it's device id b) if the device id is ok for use in the server's records, then the server will communicate with the client normally.