Page 1 of 1

Questions about the UI - daemon communication protocol

Posted: Thu Aug 11, 2016 10:41 am
by kkmic

Regarding the protocol used by the GTK client and the daemon when communicating:

I have asked about it on the IRC the other day and bendikro pointed me to this page:

Thanks for that!

After reading it, I have noticed that there is no RPC method that seems to be used for authentication, and after a bit code digging I have pieced together the following simplified scenario of a client-daemon session:
  1. The client opens a SSL socket to the server (and it does not seem to validate the certificate in any way).
  2. The client uses the 'daemon.login' RPC method to authenticate.
  3. Assuming correct credentials, the client will listen for events from the daemon and send RPC requests as needed.
  4. The connection is closed by either party at the end.

My questions are:
  1. Is the 'daemon.login' method documented somewhere? If so, please point me in the right direction
  2. Are there any other methods that are used during authentication, besides the 'daemon.login' one?
  3. Is the SSL certificate really not validated by the client when connecting or I have read the code wrong?
  4. Where are the events emitted by the daemon documented

Re: Questions about the UI - daemon communication protocol

Posted: Wed Aug 17, 2016 7:31 am
by kkmic

If my questions need further clarification, please tell me.

The basic idea is that I am looking to implement the protocol in my Java application.

Considering that my experience with Python is extremely limited, I would really appreciate some help in understanding the protocol.

Re: Questions about the UI - daemon communication protocol

Posted: Thu Jun 15, 2017 8:11 am
by Jay-C
I can answer 3 for you. Saying that "all communication between the GTK UI and daemon is encrypted" is misleading. The certificate is generated automatically and is self-signed, so it can per definition not be validated, so it can just as easy be a man-in-the-middle trying to intercept your traffic. This setup only protects against a passive adversary. This might be enough for a trusted local network, but you should not expose the daemon control port to the internet. Use SSH tunneling instead.