Implement challenge response on initial connections to rvd

[gkc]

Is your feature request related to a problem? Please describe.

• rvd's job is to allow two processes running on separated networks to establish a socket connection between them, via ports which the rvd assigns and then listens on
• Currently, some other process can in theory connect to a newly-opened rvd port in the brief window before the intended process has done so
• We would like to prevent this in a cryptographically secure way

Describe the solution you'd like

• When requesting a port pair from the rvd via atProtocol, the requesting atClient should provide a unique one-time session ID as well as the atSigns of the two processes which are attempting to communicate. (Note that the same atSign could be being used by both processes)
• When a process tries to create a client socket to a port that the rvd has made available, then
  • the rvd will know what atSign should be connecting to that port
  • and the rvd will know the session ID
  • the rvd can therefore require the client to provide a base64-encoded cryptographic signature where the data being signed is the session ID, and the signing key is the client atSign's private encryption key
  • the rvd can then verify the signature using the client atSign's public encryption key
• If the client process does not supply a valid signature then the rvd should drop the connection
• If the client process has supplied a valid signature then the rvd can proceed as it currently does, and join this socket's i/o to the other process's socket's i/o (once the other socket client has also presented a valid signature)

[VJag]

This task has the following sub-tasks:

Socket connector: Enable conditional data flow. i.e. the clients connected to the sockets joined should authenticate themself by sending signed session IDs. The socket connector will only let the data flow after authenticating the clients by verifying the signature of the session ID.

Design concerns: Backwards compatibility, Pluggable authentication, and Right naming convention (we need to pass sessionId in clear, client atSign and the device atSign)

rvd: Needs to have the knowledge to decide whether to call serverToServer the old one or the new serverToServer that will authenticate the clients.

sshrv process: Need to have the information to determine whether to utilize unauthenticated socket joining method or the authenticated socket method. Then the ability to authenticate itself with the signed session ID.

[VJag]

Almost done with the Socket connector part, will raise a PR in a day or two.

[VJag]

Pending items:

• [x] Plug-in SocketAuthenticator in SshrvImplExec
• [x] Run SSHRV process on the client side

[gkc]

Work is complete; socket_connector unit tests are complete; sshnoports unit tests are WIP; PRs need to be finalized and merged. 2 SP remaining for this and 2 SP for #626 which is addressed by the same PRs

[gkc]

Reducing to 1SP for final PR merge once e2e test overhaul has been completed as part of #659