Auto connection request for avahi


#21

Currently, without authentication this would appear to allow any user on the local network to control a machine as soon as someone installs deskconn? And so the only difference with avahi-control is that it can be advertised - so someone passively connected to the same network could become aware there is now another machine which they could easily control (whereas previously they would have had to actively scan for such a machine via nmap or similar).

I agree with @jdstrand this appears too much of a security risk for the user (in either case but especially in the case with avahi-control) so I also vote -1 on auto-connect until an authorisation & authentication mechanism is implemented so that only trusted devices on the same network can control deskconn.


#22

The authentication mechanism is in place now, a non-authenticated client on the network is no longer able to access/control the computer.

Below is how the mechanism works

  1. the desktop computer calls the command deskconn.pair
    ==> that prints an OTP (valid only for 30 seconds)
  2. The client (could be an Android phone) then generates a SigningKey and sends its newly generated public key and the otp to the computer
    ==> If the OTP is found to be “correct”, then the public key is saved in a database
    ==> That completes the pairing

All further communication happens using WAMP-Cryptosign authentication https://crossbar.io/docs/Cryptosign-Authentication/ which is end-to-end encrypted using Curve25519 (an overkill, maybe ?)

The change is in the edge channel and will be moved to “stable” once that manual review gets approved https://dashboard.snapcraft.io/snaps/deskconn/revisions/82/